S'organiser en équipe sous Git

S'organiser en équipe sous Git

30 avril 2021

Travailler en équipe demande de l'organisation et encore plus quand plusieurs développeurs travaillent ensemble sur un même dépôt Git. Vive les conflits de codes !

Les conflits vous n’y échapperez pas malheureusement, mais il est possible d’organiser le tout afin de minimiser ses conflits justement.

La méthodologie que je vous propose n’est pas la solution ultime, sachez-le. C’est une approche que je trouve logique, mais demande un minimum de rigueur de la part de l’équipe. L’idée repose sur un système multiple de branches sur votre dépôt Git. Ça en facilitera la lecture et la compréhension de celui-ci en même temps.

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é. Son travail sera de 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 ?

Malheureusement, ç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 aussi au développement pour ne pas perdre le fil ajouté. La fusion réalisée, supprimez cette branche ?.

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