Notre projet de GMAO full-web est en développement depuis près de deux ans et est en production depuis plus de dix-huit mois. Je présente donc ici le workflow Git que nous avons utilisé et qui s'est montré très efficace jusqu'à présent.

Contexte

• Plusieurs développeurs ;
• Plusieurs instances de pré-production, plusieurs serveurs de production (versions de code non synchrones) ;
• Releases mensuelles avec livraison en pré-production, puis sur le(s) serveur(s) de production ;
• Sur les serveurs, la base de code est récupérée depuis le dépôt Git avec Fabric.

Règles

Pour gérer ceci, nous avons mis en place quelques règles simples :

1. Un (et un seul) mainteneur, qui gère le dépôt Git et les releases ;
2. Ne jamais commiter directement sur la branche master ;
3. Ne jamais faire de rebase de master sur une autre branche ;
4. Ne pas sortir du workflow prévu.

Workflow

Branche master

Notre branche master est le tronc commun et contient simplement toute la base de code de la prochaine release. Puisque nous ne commitons pas directement sur cette branche, elle n'avance quasiment que par des commits de merge.

Branches de développement

Quand un développeur commence une nouvelle fonctionnalité ou une correction de bug, il crée une nouvelle branche depuis le HEAD de master.

    
    $ (master) git checkout -b featureA
    $ (featureA) git commit -a -m "featureA part 1"
    $ (featureA) git commit -a -m "featureA part 2"

Le développeur suit l'évolution de la branche master et vérifie régulièrement que son code fonctionne toujours en faisant un rebase de sa branche de développement (featureA) sur la branche master.

     
    $ (featureA) git rebase master

Quand ses développements sont terminés (commits *fa1* / *fa2* dans le schéma ci-dessous), il fait un dernier rebase. Grâce à cela :

• il s'assure que le mainteneur pourra merger son code facilement (le mainteneur ne doit pas avoir à lire le code en profondeur, ni à chercher pourquoi il y a un conflit ou un bug) ;
• si les tests passent sur la branche de développement juste après le rebase, ils passeront aussi sur master, on s'assure donc que la branche master est toujours pleinement fonctionnelle.

Le mainteneur peut tranquillement merger cette branche dans master, sans problème de conflits. L'attribut --no-ff permet de forcer un commit de merge, ce qui permet d'avoir un historique parfaitement lisible (il est facile de voir où une branche a commencé et où elle a été mergée).

    $ (master) git merge --no-ff featureA

Une fois sa branche de développement mergée, il est préférable que le développeur la supprime :

    $ (master) git branch -d featureA
    $ (master) git push origin :featureA

Branches stables

Préparer une release revient à mettre à jour le fichier CHANGELOG (avec ce workflow, la commande git log --oneline donne un résumé assez clair et concis), tagger la branche master (optionnel) et démarrer une nouvelle branche stable.

    $ (master) git tag 1.0
    $ (master) git checkout -b stable1.0
    $ (stable1.0) git push origin stable1.0

Note : Le tag et la branche ne doivent pas porter le même nom.

Cette branche stable est déployée sur les différents serveurs.

Pendant que les développements avancent, il peut être nécessaire de réaliser des corrections urgentes (commit hf1 dans le schéma ci-après), qui doivent être déployées en production rapidement. Ces corrections sont faites directement sur la branche stable concernée, ce qui assure de n'avoir aucun commit qui descende de master vers une branche stable de manière incontrôlée.

Régulièrement, le mainteneur merge la branche stable dans master pour récupérer ces commits de correction. Cette action est particulièrement importante avant la release suivante.

    $ (master) git merge --no-ff stable1.0

Cette méthode s'est montrée très efficace et très fiable car :

• chaque branche stable a sa propre vie et n'est pas impactée par l'évolution de master. Il est donc possible de réaliser des corrections très rapidement sans se préoccuper des développements réalisés depuis la dernière release ;
• il est assuré qu'aucune correction n'a été perdue avant la release suivante, ce qui évite les régressions.

Un exemple plus complet d'historique

Conclusions

Bien sûr, il y a de multiples workflow Git qui peuvent se montrer efficaces, mais nous avons trouvé beaucoup d'avantages à travailler avec celui-ci, sans avoir eu de réel problème :

• La branche master est toujours propre et fonctionnelle ;
• Les développeurs n'ont pas à se préoccuper du workflow Git complet ;
• Des corrections peuvent être déployées rapidement, sans stress ;
• Chaque release stable contient les nouvelles fonctionnalités et les éventuelles corrections ;
• Travailler dans des branches systématiquement et utiliser l'option --no-ff permet d'avoir un historique vraiment clair ;
• Ce workflow est évolutif (un accroissement du nombre de branches ou de développeurs n'a pas vraiment d'impact).

Restons connectés !

• Si cet article vous a intéressé, suivez-nous sur Twitter : @makina_corpus, @__fle__
• This post in english here : An efficient GIT workflow for mid/long time projects

Offre de formation GIT

Makina Corpus dispose d'experts GIT, vous pouvez retrouver notre formation GIT ou nous contacter.