Bien gérer le contrôle de version avec Git

1. Définir une stratégie de branche unique

   • Quand des membres de l’équipe aux expertises variées travaillent ensemble, leurs approches du workflow peuvent entrer en conflit
   • Pour éviter cela, le responsable doit définir une stratégie de branche unique et la diffuser à toute l’équipe
   • Le choix du workflow de branches peut varier selon plusieurs facteurs, comme la taille de l’équipe, son niveau d’expérience, les besoins de montée en charge ou les contraintes opérationnelles
   • L’équipe de développement peut suivre un workflow déjà établi ou en concevoir un adapté à ses besoins
   • Ce que peut inclure un workflow
     • Workflow centralisé : un seul dépôt et une seule branche master. Il existe un risque d’écrasement des modifications
     • Branche de fonctionnalité : une nouvelle branche est créée à chaque ajout de fonctionnalité. Les commits liés à cette fonctionnalité sont faits dans la branche feature correspondante
     • Git Flow : une forme plus poussée de la branche de fonctionnalité. Avec Git Flow, on dispose d’une branche master et d’une branche de développement distincte. Des branches de fonctionnalité, de release et de hotfix sont prises en charge. Le développement se fait dans la branche de développement, passe par une branche de release, puis est fusionné dans la branche master
     • Développement task-branch : GitLab Flow en est un exemple. Il s’agit d’une approche orientée fonctionnalités qui combine les branches feature avec le suivi d’issues. GitLab Flow utilise aussi des branches dédiées pour gérer plusieurs environnements comme le staging, les tests de production et la production. Cela permet de vérifier que les modifications commit sont testées sur l’ensemble des environnements
   • Effets sur la collaboration :
     • Quand tout le monde travaille en harmonie selon le même workflow, le risque d’écraser du code ou d’endommager la branche master diminue
     • Tous les intervenants se familiarisent avec le processus de développement et de déploiement, ce qui permet aux membres de l’équipe de contribuer plus facilement au travail des autres
     • Une stratégie de branche claire et concise crée un cercle vertueux pour fusionner du nouveau code et faire progresser le projet
     • Un tel environnement aide les membres de l’équipe à organiser des réunions et à gérer les échéances ainsi que la charge de travail
     • Impact de chaque workflow sur la collaboration
       • Workflow centralisé : efficace pour les petites équipes capables de bien communiquer afin que deux développeurs ne travaillent pas en doublon en même temps sur le même code (moins de 5 développeurs)
       • Branches de fonctionnalité et GitFlow : impliquent davantage de revues de code, de règles de push, d’approbateurs de code et de tests plus étendus, ce qui connecte un plus grand nombre d’équipes
       • Développement task-branch : pousse les membres de l’équipe à décomposer les besoins en petits blocs de fonctionnalités transmis sous forme de branches de tâche. Ce workflow inclut des pratiques collaboratives comme les extraits de code, les revues de code et les tests unitaires. En cas d’échec d’un test, les membres collaborent pour identifier l’origine du problème

2. Commiter souvent en petites unités

   • Si l’on donne la priorité à l’achèvement complet, on risque de ne faire que de gros commits quand le projet est presque terminé
   • Si l’on saute les validations simples de fonctionnalités et les petites étapes, on peut développer des fonctionnalités erronées ou perdre du temps dans une mauvaise direction
   • Faites un commit chaque fois que vous disposez de tests fonctionnels et de code opérationnel
   • Il faut simplifier le projet en petites étapes et trouver un moyen d’atteindre de grands objectifs grâce à des commits fréquents
   • Effets sur la collaboration :
     • Une culture du commit fréquent donne à chacun de la visibilité sur le dépôt de code et permet de savoir plus facilement sur quoi travaillent les autres
     • Le partage du travail dans une branche feature ou une merge request peut éviter que d’autres membres de l’équipe fassent le même travail en doublon
     • Même si le travail n’est pas encore prêt à être relu, il faut pousser fréquemment sur la branche feature
     • Partager le travail avant qu’il soit terminé stimule les discussions et les retours, ce qui permet d’améliorer la qualité avant même la revue de code
     • Découper le travail en plusieurs commits fournit des informations utiles pour les futures revues de code par les développeurs et les autres équipes
     • Il devient possible d’identifier clairement, commit par commit, comment une fonctionnalité a été développée
     • On peut revenir à un point précis dans le temps ou annuler sélectivement certains changements de code tout en conservant l’historique des modifications non liées

3. Rédiger des messages de commit détaillés

   • Un message de commit doit refléter non seulement le contenu du commit, mais aussi l’intention du développeur
   • Le message de commit doit expliquer pourquoi la modification a eu lieu
   • Exemple de bon message de commit : « Fusion des templates pour réduire le code dupliqué dans l’interface utilisateur »
   • Des mots comme « changement », « amélioration », « correction » ou « refonte » dans un message de commit n’apportent pas d’information utile
   • Effets sur la collaboration :
     • Des messages de commit détaillés renforcent la transparence et la visibilité sur l’avancement, aidant les coéquipiers, les clients et les futurs contributeurs à comprendre le processus de développement
     • Lors d’une revue de code, les messages de commit aident à suivre des procédures répétées et à vérifier les changements apparus après une release, une concertation ou une modification des exigences
     • Des messages de commit détaillés aident les équipes QA et sécurité à identifier les zones problématiques lors de l’inspection du code et à revenir sur des changements spécifiques
     • Rédiger des messages de commit détaillés évite le travail en doublon entre les membres de l’équipe, réduit les retards et aide à faire progresser le projet de manière stable

4. Développer avec des branches

   • Développer dans une branche revient à travailler sur une copie de l’état actuel à un instant donné dans une branche spécifique
   • L’utilisation des branches permet de modifier le code sans affecter la base de code principale
   • L’historique des changements est géré à l’intérieur de la branche
   • Une fois le code prêt, il peut être fusionné dans la branche master
   • Coder dans des branches permet d’aborder le développement de manière plus structurée
   • Il devient possible de gérer séparément les brouillons en cours de développement et le code master stable déjà testé
   • Effets sur la collaboration :
     • Cela permet aux membres de tenter des solutions innovantes et des expérimentations pour résoudre des problèmes complexes
     • L’équipe de développement peut relever des défis créatifs sans l’angoisse d’affecter la branche master
     • Les équipes peuvent collaborer pour vérifier qu’une solution fonctionne correctement avant sa fusion dans la branche master
     • Les équipes opérations, QA et sécurité peuvent relire le code avant le déploiement, et chacun a l’occasion de proposer des idées et de discuter des problèmes potentiels avant la release

5. Effectuer régulièrement des revues de code

   • Elles garantissent l’amélioration continue et évitent l’introduction de code instable
   • Dès qu’il y a du code à examiner, il faut demander une revue à un collègue, à un membre de l’équipe ou à un expert métier connaissant bien le projet
   • Points d’attention lors d’une revue de code :
     • Expliquer quels changements sont nécessaires
     • Proposer des alternatives, tout en partant du principe que le développeur y a déjà réfléchi
     • Même pendant la résolution du problème, il faut chercher des moyens de simplifier le code
   • Effets sur la collaboration :
     • La revue de code apporte d’autres points de vue sur la résolution du problème et sur l’implémentation
     • C’est un regard supplémentaire pour détecter des bugs, des problèmes de logique ou des cas limites potentiels
     • Elle aide à atténuer les problèmes qui peuvent surgir lorsqu’on traverse des sujets difficiles en avançant vers la release
     • Elle permet d’examiner des solutions, de donner un avis et de réaliser des revues en collaboration avec les membres de l’équipe
     • Elle permet aussi d’apprendre différentes façons de coder, des savoir-faire liés aux workflows et de nouvelles méthodes de résolution de problèmes