Git Workflow for Small Teams (Keep It Simple)

Le mardi dernier, j'ai regardé un développeur junior passer quarante-cinq minutes à essayer de comprendre pourquoi leur branche de fonctionnalité ne pouvait pas être fusionnée. Le coupable ? Le flux de travail Git beaucoup trop complexe de notre équipe, qui impliquait quatre types de branches différents, des protocoles de rebase obligatoires et une stratégie de fusion qui nécessitait un organigramme pour être comprise. Je dirige des équipes d'ingénierie depuis douze ans, et je peux vous le dire avec une certitude absolue : la plupart des petites équipes sont submergées par une complexité Git dont elles n'ont pas besoin.

Je suis Sarah Chen, et j'ai passé la dernière décennie à construire et à faire évoluer des équipes de développement dans trois startups différentes. J'ai vu des équipes de cinq développeurs utiliser des flux de travail conçus pour des organisations comptant cinq cents ingénieurs. J'ai regardé de brillants programmeurs perdre des heures à naviguer dans des stratégies de ramification qui n'ajoutent aucune valeur à leur travail réel. Et j'ai appris que, lorsqu'il s'agit de flux de travail Git pour les petites équipes—disons de deux à dix développeurs—la simplicité n'est pas juste un luxe. C'est la différence entre livrer des fonctionnalités et livrer de la confusion.

Voici ce que personne ne vous dit : Git est incroyablement puissant, ce qui signifie qu'il est également incroyablement facile à compliquer. Internet regorge d'articles sur Git-flow, GitHub flow, GitLab flow, développement basé sur le tronc, et une douzaine d'autres stratégies. La plupart d'entre elles résolvent des problèmes que vous n'avez pas. , je vais vous montrer le flux de travail Git qui a permis à mes équipes d'être productives, heureuses et de livrer du code sans la surcharge d'une complexité de niveau entreprise.

Pourquoi la plupart des flux de travail Git échouent pour les petites équipes

Avant d'aborder ce qui fonctionne, parlons de ce qui ne fonctionne pas. J'ai hérité de bases de code provenant d'équipes qui utilisaient Git-flow avec sa branche de développement, des branches de version, des branches de correctifs et des branches de fonctionnalités. Pour une équipe de quatre développeurs travaillant sur un produit SaaS avec des versions hebdomadaires, c'était un véritable excès.

Le problème avec les flux de travail complexes n'est pas qu'ils soient erronés—c'est qu'ils résolvent des problèmes qui émergent à grande échelle. Git-flow a été créé par Vincent Driessen en 2010 pour un contexte spécifique : des équipes gérant plusieurs versions de production simultanément, avec de longs cycles de publication et la nécessité d'une gestion étendue des correctifs. Si vous êtes une petite équipe livrant en continu à un seul environnement de production, vous portez tout le poids de Git-flow sans aucun de ses avantages.

J'ai réalisé une expérience l'année dernière avec deux équipes de taille et de niveau de compétence similaires. L'équipe A a utilisé un flux de travail simplifié que je vais décrire. L'équipe B a utilisé le Git-flow standard. Pendant trois mois, l'équipe A a livré 23 % de fonctionnalités en plus et a rapporté des niveaux de frustration significativement plus bas dans notre enquête trimestrielle. La différence n'était pas dans le talent ou l'effort—c'était dans la friction. Chaque type de branche supplémentaire, chaque étape de fusion additionnelle, chaque opération de rebase complexe augmente la charge cognitive et ralentit votre équipe.

Les petites équipes ont des contraintes différentes de celles des grandes organisations. Vous n'avez probablement pas de gestionnaires de version dédiés. Vous n'avez probablement pas besoin de prendre en charge plusieurs versions de production. Vos développeurs portent plusieurs chapeaux et changent fréquemment de contexte. Votre flux de travail devrait refléter ces réalités, et non se battre contre elles. Quand je vois une équipe de cinq personnes utiliser la même stratégie Git que Google, je sais qu'ils optimisent pour des problèmes qu'ils espèrent avoir un jour au lieu des problèmes qu'ils ont aujourd'hui.

Le coût de la complexité se cumule avec le temps. Un développeur qui passe dix minutes par jour à naviguer dans un flux de travail Git inutilement complexe perd plus de quarante heures par an—une semaine de travail entière—rien que pour gérer les branches. Multipliez cela par votre équipe, et vous obtenez des semaines de productivité perdues chaque année. Cela ne prend même pas en compte le temps passé à résoudre des conflits de fusion qui n'existeraient pas dans un flux de travail plus simple, ou l'énergie mentale drainée par le fait de devoir constamment se souvenir de quelle branche fusionner dans quelle autre.

La philosophie des deux branches : principale et fonctionnalité

Voici le flux de travail qui a fonctionné pour chaque petite équipe que j'ai dirigée : deux types de branches, point final. Vous avez la branche principale (ou maître, si vous travaillez avec des dépôts plus anciens), et vous avez des branches de fonctionnalités. C'est tout. Pas de branche de développement, pas de branches de version, pas de branches de correctifs. Juste principale et fonctionnalités.

Git est incroyablement puissant, ce qui signifie qu'il est également incroyablement facile à compliquer. La plupart des équipes résolvent des problèmes qu'elles n'ont pas.

Votre branche principale représente la production. Tout ce qui se trouve dans la branche principale doit être déployable à tout moment. C'est non négociable. Si la branche principale n'est pas déployable, votre flux de travail a échoué. Ce principe unique élimine une énorme quantité de complexité car il signifie que vous travaillez toujours vers un objectif clair : amener votre code dans un état où il peut fusionner en toute sécurité dans la branche principale.

Les branches de fonctionnalités sont là où tout le travail se passe. Vous démarrez une nouvelle fonctionnalité ? Créez une branche à partir de la branche principale. Vous corrigez un bug ? Créez une branche à partir de la branche principale. Vous refactorez un code ? Créez une branche à partir de la branche principale. Le schéma est cohérent et prévisible. Il n'y a pas de tableau de décision sur quelle branche ramifier ou dans quelle branche fusionner. Chaque branche de fonctionnalité a le même cycle de vie : ramifier à partir de la branche principale, faire votre travail, fusionner de nouveau dans la branche principale.

Je nomme les branches de fonctionnalités avec une simple convention : type/brève-description. Par exemple : fonctionnalité/authentification-utilisateur, correction-bug/renvoi-login, refactorisation/client-api. Le préfixe de type rend immédiatement clair quel type de travail se déroule, et la description est lisible par des humains. J'ai vu des équipes utiliser des numéros de ticket (fonctionnalité/JIRA-1234), mais je trouve cela moins intuitif lorsque vous regardez une liste de branches. Vous voulez pouvoir scanner vos branches et immédiatement comprendre sur quoi on travaille.

La beauté de cette approche réside dans sa prévisibilité. Un nouveau développeur qui rejoint votre équipe peut comprendre l'ensemble de votre flux de travail Git en environ cinq minutes. Il n'y a pas de diagramme de ramification complexe à mémoriser, pas de cas spéciaux à retenir. Ramifiez à partir de la branche principale, faites votre travail, fusionnez dans la branche principale. Cette simplicité a un effet d'accumulation sur la productivité. Lorsque votre flux de travail est simple, les développeurs dépensent moins d'énergie mentale sur le processus et plus sur la résolution de problèmes réels.

Une question que je reçois fréquemment : que faire des fonctionnalités de longue durée qui prennent des semaines à être complétées ? N'avez-vous pas besoin d'une branche de développement pour cela ? Non. Vous avez besoin de fonctionnalités masquées. Si une fonctionnalité n'est pas prête pour les utilisateurs, cachez-la derrière un masque. Cela maintient votre code intégré en continu tout en vous donnant le contrôle sur le moment où les fonctionnalités deviennent visibles. J'ai vu des équipes créer des stratégies de ramification élaborées pour résoudre des problèmes que les fonctionnalités masquées résolvent plus élégamment.

Les Pull Requests : votre porte d'entrée qualité

Chaque branche de fonctionnalité fusionne dans la branche principale par le biais d'une pull request. Pas d'exception. Je me fiche de savoir si vous êtes le CTO ou si c'est un changement d'une ligne. Les pull requests ne concernent pas seulement l'examen du code—elles concernent la création d'un moment de prise de décision délibérée avant que le code n'entre en production.

Voici mon modèle de pull request, que j'ai affiné au fil des ans grâce à des expériences. Il est court car les longs modèles ne sont pas remplis correctement. Chaque pull request doit inclure : une brève description de ce qui a changé, pourquoi cela a changé, et comment le tester. C'est tout. Trois sections, chacune généralement de trois à cinq phrases. Si vous ne pouvez pas expliquer votre changement dans cet espace, votre changement est probablement trop vaste.

Pour l'examen du code, je suis une règle simple : chaque pull request a besoin d'au moins une approbation avant de fusionner, mais la personne qui l'approuve partage la responsabilité de tout problème qui pourrait survenir. Cela crée la bonne structure d'incitation. Les réviseurs prennent leur rôle au sérieux car ils ne font pas que tamponner—they're co-signing. En même temps, une approbation suffit car nous sommes une petite équipe et nous nous faisons confiance. Exiger deux ou trois approbations peut avoir du sens pour une équipe de cinquante, mais pour une équipe de cinq, cela ne fait que ralentir les choses.

J'ai expérimenté différentes attentes concernant le délai de retour des examens. Ce qui fonctionne le mieux : les réviseurs devraient fournir des retours dans les quatre heures pendant les heures de travail. Pas quatre heures de temps de révision concentré—quatre heures pour au moins reconnaître la pull request et fournir un retour initial. Cela maintient le code en mouvement sans créer une attente de réponse instantanée. Si quelqu'un a besoin de plus de temps pour une révision approfondie, il commente en disant ainsi, et l'auteur sait qu'il peut s'attendre à des retours détaillés plus tard.

Une pratique qui a considérablement amélioré notre qualité de code : exiger que l'auteur de la pull request fusionne son propre code après approbation. Cela peut sembler un petit détail, mais cela change le comportement. Quand vous savez que vous serez celui qui cliquera sur le bouton de fusion, vous êtes plus prudent concernant vos changements. Vous