Adoptez un modèle de branches !

Ainsi que nous l’avons déjà évoqué dans un précédent article, les outils de collaboration basés autour du code sont un atout indéniable pour votre équipe de projet, ce d’autant que GIT est un outil très souple et puissant. Ce dernier n’est cependant pas prescripteur au niveau des pratiques qui vont régir son utilisation : il est donc nécessaire de fixer en amont les règles d’un modèle de branches.

Un « modèle de branches » ?

Je ne veux pas rentrer ici dans les détails techniques de GIT, qui sont déjà abondamment présentés sur de nombreux sites. Voici cependant quelques éléments généraux pour introduire notre sujet.

Attardons-nous tout d’abord un instant sur le sens de cette expression qui a très mal franchi la barrière de l’anglais, où l’on parle en fait de branching model — une traduction plus exacte serait en fait « un modèle de création de branches ».

Les branches sont un des éléments distinctifs de GIT vis-à-vis des autres logiciels de gestion de versions : il est en fait extrêmement simple pour n’importe quel utilisateur de générer une branche à partir d’une autre. Cette dernière n’existera alors qu’en local sur sa machine à moins qu’il ne décide de la pousser sur le serveur distant, l’origin.

À l’inverse, rapprocher une branche d’une autre pour y intégrer les modifications dont elle est porteuse est également extrêmement simple : pour peu qu’aucun conflit ne survienne, l’opération est traitée en une simple commande.

Ces opérations de création et de jointure de branches sont donc très simples à réaliser … Un peu trop simples, peut-être ? Comment nous assurer, par exemple, qu’un fichier ne va pas accidentellement se retrouver dans une branche destinée à passer rapidement en production ?

Organiser le chaos

Vous l’avez compris, ces opérations peuvent être effectuées dans tous les sens : afin de garder le contrôle sur la base de code versionnée, il est nécessaire de fixer à tous un certain nombre de règles à respecter lors de l’utilisation de GIT : c’est l’objet même du modèle de branches.

Voici quelques exemples concrets de règles qui peuvent être ainsi être définies avec l’équipe de développement :

• deux branches principales seront utilisées respectivement pour l’environnement de recette et la production : respectivement develop et master ;
• les développements de fonctionnalités se feront systématiquement sur des branches à part, toujours branchées à partir de la branche develop — une fois terminées et validées, les modifications rejoignent la branche de develop ;
• le passage d’une fonctionnalité en production est provoqué par une fusion de la branche develop dans master, puis par la création d’un tag dont le format est normalisé, par exemple v2017.04.28-1 ;
• etc.

Ces règles simples, si elles sont suivies par tous, peuvent déjà permettre d’améliorer la situation — mais elles peuvent déroutantes pour les débutants qui utilisent GIT depuis peu, et peuvent aussi être oubliés (voire omises) par les autres. En cas de mauvaise communication, nous ne sommes pas à l’abri que de mauvaises habitudes refassent surface.

Git-Flow à la rescousse

Git-flow est un modèle de branches tout prêt qui va justement vous permettre de mettre en place facilement une solution clé-en-main pour répondre à vos besoins en matière d’organisation. Un certain nombre de choix, de décisions et d’arbitrages ont déjà été faits pour vous, il n’y a plus qu’à apprendre les règles de son fonctionnement et à le suivre.

Pour vous y aider, Git-Flow est disponible comme une extension de GIT qui va venir ajouter à l’outil en CLI un certain nombre de commandes supplémentaires qui sont en fait de simples macros qui respectent le modèle.

Ces commandes de haut niveau rendent l’utilisation de GIT plus simple et accessible à tous en automatisant les opérations atomiques qu’elles vont réaliser (création / suppression / merge de branches, ajout de tag, etc.).

Voici quelques exemples :

• créer / achever une fonctionnalité : git flow feature start nouveau-moteur-de-recherche / git flow feature finish nouveau-moteur-de-recherche ;
• créer / achever une version à passer en production : git flow release start v2017.04.28-1 / git flow release finish v2017.04.28-1 ;
• etc.

La courbe d’apprentissage de Git-Flow est assez faible, ainsi que l’illustre ce site qui résume le fonctionnement de chacune des commandes de façon très visuelle.

La fin de l’histoire ?

Git-Flow est en fait une compilation de bonnes pratiques liées à un usage « classique » de GIT … Il n’est toutefois pas si rare de rencontrer des formes d’organisation ou de collaboration trop complexes pour être implémentées à travers ce modèle.

Dans un tel cas de figure, rien ne vous empêche alors de vous inspirer de ce modèle de branches pour constituer le vôtre qui tiendra compte de vos spécificités.

Utilisez-vous Git-Flow au quotidien, ou bien votre propre modèle de branches ? Laissez donc un commentaire pour partager vos expériences à ce sujet !