Gestion efficace des branches Git pour minimiser les conflits de code

Travailler en équipe demande de l'organisation, particulièrement quand plusieurs développeurs collaborent sur un même dépôt Git. Les conflits de code sont inévitables, mais une bonne stratégie de gestion des branches peut aider à les minimiser. Dans cet article, je partagerai une méthodologie qui a fait ses preuves dans la gestion efficace des branches et la réduction des conflits.

Branche de production

Quand vous créez votre dépôt la première fois, une branche "master" est automatiquement mise en place. Cette branche nous servira de repère pour la suite, mais possède aussi un rôle capital dans l’organisation.

Sur la branche "master", vous déposerez la base de votre projet, par exemple, si vous travaillez avec un framework, déposez sur cette branche les fichiers de ce framework une fois le projet généré avec.

Le code de cette branche doit être 100% fonctionnel ! Il ne doit y avoir aucun conflit, aucun problème, aucun bug (dans la mesure du possible). C’est cette branche qui contient le code de votre projet qui sera envoyé en production, donc comprenez bien que ce code doit être de qualité.

Afin d’éviter tout problème, un seul gestionnaire sera nommé. Il devra fusionner d’autres branches dans la branche "master" après s’être assuré que tout fonctionne auprès des développeurs. Attention, ça ne fait pas de lui un chef de projet, calmez-vous ?

Branche de développement

Vous l’aurez compris, cette branche nommée "develop" est une duplication de la branche "master" et peut être récupérée par les développeurs pour travailler. C’est dans celle-ci que tous les commits iront pour ajouter de nouvelles fonctionnalités à votre projet.

Ce n’est pas pour autant un fourre-tout !

Utilisez cette branche pour les petites corrections mineures. Celles qui ne compromettent pas le projet dans son intégralité. Si un développeur doit implémenter une nouvelle fonctionnalité, une nouvelle branche sera créée à partir de la branche "develop", qui sera dédiée à cette nouvelle fonctionnalité. De là, un ou plusieurs développeurs pourront travailler dessus.

Une fois cette fonctionnalité terminée, vérifiée, elle sera fusionnée dans la branche "develop" et non pas "master". Quand "develop" possédera un code correct et que vous estimez que les nouveautés doivent passer en production, le responsable pourra merger celle-ci dans la branche "master" et envoyer votre code en production sur votre serveur.

Ce que vous pouvez faire aussi avant de fusionner "develop" et "master", c’est générer une release dans "develop" qui sera intégrée à la branche "master" au moment du merge.

Bugs en production ?

Ça arrive. Pas de panique, dans un cas comme celui-ci, vous allez appliquer un hotfix, c’est-à-dire une correction directement sur le code de production. Pour cela, créez une branche "hotfix" à partir de "master". Corrigez le bug en question et fusionnez la correction à la production, mais également au développement pour ne pas perdre le fil ajouté. La fusion réalisée, supprimez cette branche ?

Comme je vous l’ai déjà expliqué, ce n’est pas la solution ultime, mais avec de la discipline, cette organisation tient durablement la route, évite les commits à répétition n’importe où et permet de garder une certaine traçabilité propre et un code sain.