Gitflow : pour un développement sans conflit

La traçabilité du code est essentielle dans un projet web surtout si on travaille en groupe. Il faut être en mesure de savoir qui a fait quoi, quand et pourquoi il l’a fait. Pour répondre à ce problème, des gestionnaires de versionning ont été inventés. Ces derniers permettent d’avoir un historique détaillé de toutes les modifications du code source et de structurer le processus développement. Il en existe plusieurs : SVN, Mercurial, CVS, Bazaar, mais aujourd’hui, nous allons nous concentrer sur Git et plus particulièrement Gitflow parce qu’il est très efficace et qu’on l’utilise chez Vigicorp.

Le fonctionnement de Gitflow

À l’origine, il y a Git. Git est un gestionnaire de versionning, c’est-à-dire qu’il permet de gérer les différentes versions de votre code. À partir de ce gestionnaire, on peut organiser son travail comme on le souhaite. Concrètement cela consiste en la création de branches qui aident à structurer votre développement. Gitflow lui est un standard. Une structure de base que les gens peuvent utiliser et qui a fait ses preuves par son efficacité.

Une branche = une fonction

Voilà à quoi cela ressemble. Pas de panique ! On vous explique :

La branche Master

La branche Master est la branche principale. Elle doit être la branche la plus stable, car ces versions sont proposées au client. Chacune des modifications (plus communément appelées commit) de cette branche est une nouvelle version, cependant les développeurs ne travaillent jamais directement à partir de la branche master. Pour faire évoluer le code, on passe par la branche Develop.

La branche Develop

La branche Develop est celle qui va contenir l’historique complet du code, car elle est amenée à recevoir toutes ses modifications, qu’elles soient mineures ou majeures. Cependant, cette version doit rester stable, c’est pourquoi les développeurs ne peuvent travailler dessus que pour des modifications mineures : correction de bugs ou petites améliorations.

Quel est le risque ? Que des conflits interviennent au cours du développement d’une nouvelle fonctionnalité. Cela arrive lorsque plusieurs développeurs ont modifié une même partie du fichier. Il faut alors corriger les conflits au cours du développement pour pouvoir continuer à avancer ce qui prend beaucoup de temps et rend la branche Develop très instable.

C’est là qu’intervient la branche feature.

La branche Feature

La branche Feature est celle que les développeurs utilisent pour développer des fonctionnalités. Grâce à cette branche, le conflit ne peut intervenir que lorsque la fonctionnalité est implémentée dans la branche Develop. On dit alors qu’on merge Feature dans Develop. C’est donc un énorme gain de temps, car ça permet d’éviter de rencontrer trop de problèmes.

La branche Release

La branche Release va relier la branche Develop et la branche Master. Lorsqu’on estime qu’assez de fonctionnalités ont été implémentées dans la branche Develop on effectue ce qu’on appelle une « release », une mise à jour de la branche Master.

Pour cela, on crée une branche à partir de Develop. L’objectif de cette branche est de corriger tous les bugs sans ajouter de fonctionnalités et une fois que c’est fait on merge Release sur Master et Develop. Il est important de merger également Release sur Develop car les bugs qu’on a corrigés sont toujours présents sur cette dernière.

La branche Hotfix

Cette branche, qui intervient directement sur la branche Master est supposée être la moins utilisée. Elle sert à corriger les bugs majeurs directement sur la branche Master.

L’importance de la traçabilité du code

Les développeurs travaillent à plusieurs sur un même projet. De ce fait, avoir un historique est essentiel, car il permet de savoir qui a fait quoi, quand et pourquoi il l’a fait. Pourquoi c’est essentiel ? Car le développement d’un projet web, c’est comme la construction d’une pyramide. Ce qui est en bas est essentiel pour que le haut tienne debout. Aussi, si un problème apparaît, le régler est obligatoire pour assurer la viabilité du développement.

Cependant, il n’est pas toujours facile de savoir ce qui ne fonctionne pas en bas de la pyramide. L’historique permet donc de savoir à partir de quel moment l’erreur est apparue et donc de facilement l’identifier et la régler. Ce n’est pas qu’un simple outil qu’on peut consulter, l’historique présent sur Gitflow donne la possibilité de faire un retour en arrière. De revenir à une version antérieure et de repartir de celle-ci pour développer votre application. Cela est notamment très utile lorsqu’un gros bug intervient sur une version et qu’il est plus rapide de revenir au point de départ que d’essayer de le corriger.

Travailler en équipe avec Gitflow

Gitflow permet un développement en équipe tout en limitant les conflits. Chacun a la possibilité de travailler dans son coin pour développer des features et de les merger à n’importe quel moment dans le projet. C’est la manière d’organiser Git la plus utilisée, grâce à ses branches qui sont très efficaces, mais aussi à sa manière de gérer l’historique du code.

Logiciel de gestion de versions distribué/centralisé

Il existe deux manières pour les gestionnaires de versionning de stocker le code.

Centralisé

Dans le modèle centralisé, l’historique est exclusivement stocké sur un serveur. Dès qu’une modification est effectuée le serveur l’enregistre et la stocke. Ça permet de savoir en direct qui en est où, cependant ça reste très risqué, car l’historique du code n’est stocké qu’à un endroit.

Distribué 

Dans le modèle distribué, chacun des développeurs a son propre historique qu’il doit ensuite envoyer au serveur une fois qu’il a fini son développement. Cela permet de développer en local et d’assurer la pérennité du code qui peut être copié sur une version locale en cas de perte du serveur.

Git fonctionne selon le modèle distribué, un modèle majoritaire de nos jours et à raison, car il est beaucoup plus efficace. Ce modèle permet de facilement travailler à plusieurs sur le même projet. Chacun peut apporter des modifications au code de son côté et n’a à gérer les conflits qu’au moment de merger.