af83

Notre workflow git

Git est un outil formidable que nous utilisons depuis plusieurs années chez af83. C'est également un outil qui offre beaucoup de souplesse sur le workflow, que l'on travaille seul ou en équipe. Chez af83, notre manière de travailler avec git a évolué. Chaque développeur reste libre de travailler comme bon lui semble sur son poste mais nous sommes arrivés à quelques règles implicites sur les branches git du dépôt principal. Ce billet est l'occasion de les rendre explicites.

Master : la branche pivot

Contrairement à d'autres workflows que nous avons pu utiliser par le passé, la branche principale est master. C'est dans cette branche que le projet prend réellement forme. Tout ce qui peut être fait rapidement est commité et pushé directement dans cette branche. Pour les travaux plus compliqués, on passe par d'autres branches qui seront ensuite intégrées à master. Cette branche représente l'état en cours du projet.

En amont, des topic branches

Ainsi, master évolue rapidement mais il convient de ne pas la faire évoluer n'importe comment. Comme la plupart des développeurs s'appuient dessus, il vaut mieux éviter les commits qui empêcheraient les autres de travailler. Pour cela, nous avons d'abord l'intégration continue : Jenkins lance les tests à chaque push sur la branche master.

Mais quand un développeur voit qu'il va se lancer dans une tâche qu'il ne pourra pas finir dans la demi-journée, alors il va utiliser une branche à part. Cette tâche (ajout d'une fonctionnalité, corriger un bug, refactoring, etc.) est généralement liée à un ticket et, dans ce cas, le nom de la branche commencera par le numéro du ticket. Cette topic branch va faire avancer cette tâche et quand celle-ci sera prête, on merge la topic branch dans master puis on supprime la topic branch.

Pourquoi ne pas utiliser develop à la place de master ?

Certains préfèrent utiliser la branche develop pour intégrer les différents développements plutôt que master. C'est d'ailleurs ce que nous avions fait sur certains projets. Le sujet peut paraître très anodin, juste un nom de branche, mais il y a une autre différence : la branche master est celle sur laquelle un développeur se retrouve juste après un git clone.

Or, comme nous donnons accès à nos dépôts git à des partenaires et à nos clients, il est important que ceux-ci arrivent directement sur le projet avec les dernières avancées et un README à jour. En particulier, faire un git clone et se retrouver avec un répertoire vide peut être très déroutant et faire perdre du temps avant de comprendre qu'il faut changer de branche (oui, c'est du vécu). Aussi, je conseille d'utiliser master plutôt que develop comme branche représentant l'état en cours d'avancement du projet.

En aval, des branches pour gérer les versions

Nous souhaitons contrôler ce qui est déployé sur les différents environnements. Nous évitons donc de déployer depuis master, mais préférons passer par des branches dédiées, une pour chaque environnement. Par convention, nos branches s'appellent staging et production. Cette convention est reprise par capistrano-af83 pour déployer sur les environnements associés.

Avant de déployer sur staging, nous incorporons les changements voulus dans la branche associée (en général avec un git merge master mais parfois nous faisons du cherry-picking). Pour déployer en production, le processus est le même, avec la contrainte qu'aucun commit ne va directement en production sans être d'abord passé par staging.

Autre avantage de cette organisation, si quelqu'un nous remonte un bug, nous pouvons nous placer sur la bonne branche pour reproduire le bug, puis aller sur master pour voir si le bug existe toujours ou s'il a été corrigé entre temps.

TL;DR

Pour récapituler, notre workflow git repose principalement sur la branche master. C'est dans cette branche que la plupart des commits se font. Mais si une tâche ne peut se faire rapidement dans cette branche sans perturber les autres, on crée une topic branch pour travailler dessus, qui sera mergée dans la branche master puis supprimée. La branche master sert également à alimenter les branches staging et production, utilisées pour contrôler ce qui est déployé sur nos serveurs.

blog comments powered by Disqus