Comment choisir le workflow Git et le modèle de branchement qui conviennent à votre équipe

Git est le système de contrôle de version au cœur de presque tous les développements logiciels – il est utilisé pour stocker et suivre les modifications apportées au code que vous écrivez. Lorsque vous travaillez en équipe, il est essentiel d’avoir un flux de travail transparent qui fonctionne pour votre entreprise pour se développer rapidement.

Meilleure organisation du référentiel, développement plus rapide

Avec l’avènement de pipelines d’automatisation faciles à utiliser comme Jenkins, de nombreuses entreprises commencent à mettre en œuvre l’intégration et la livraison continues (CI/CD), les modifications apportées par les développeurs étant souvent fusionnées dans un référentiel, livrant généralement le produit une fois par semaine plutôt que base hebdomadaire. horaire mensuel.

Cette vitesse met beaucoup de pression sur votre organisation, en particulier en ce qui concerne Git. Si vous avez 50 personnes essayant de valider des modifications dans la même  master branche, vous rencontrerez des problèmes avec des conflits de fusion fréquents.

Heureusement, Git offre la possibilité de créer des branches et de choisir quand vous souhaitez fusionner du code, que chaque équipe devrait utiliser pour organiser son développement. Prendre le contrôle de votre flux de travail Git vous évitera au moins, à vous et à vos coéquipiers, de perdre du temps à rechercher de nouveaux problèmes Git sur Google.

Fonctionnalités et développement des branches

Les branches Git travaillent sur deux gros problèmes : maintenir la synchronisation de vos commandes internes et maintenir votre version publique.

Lorsque vous démarrez une branche dans Git, de nouveaux commits seront effectués sur cette branche, et non sur master. Cela peut être utile pour suivre les progrès individuels sur une fonctionnalité donnée ou des corrections de bogues ; par exemple, chaque branche peut implémenter une fonctionnalité décrite dans un ticket dans un service Kanban tel que Jira, Trello ou Github Issues & Projects.

La fusion des branches se fait généralement à l’aide de demandes d’extraction, une fonctionnalité des solutions Git hébergées comme Github où la commande demande une master extraction d’ feature une branche et intègre les modifications pour tout le monde. Cela peut être très utile pour les équipes qui effectuent des tests d’assurance qualité et des tests unitaires pour s’assurer qu’une branche fonctionne correctement avant de remonter la chaîne.

Un autre problème est la gestion de vos versions – vous ne voulez pas envoyer à vos clients une copie de votre dernière version de développement interne, car elle pourrait être corrompue par une mauvaise validation.

Pour résoudre ce problème, de nombreuses équipes utiliseront une branche distincte pour les versions et ne fusionneront cette branche que lorsqu’il sera temps de publier une nouvelle version. Cela permet plusieurs validations en arrière-plan sur la branche de développement entre les versions.

Un autre avantage de ce modèle est la possibilité de faire des commits séparés sur la branche de production, fournissant éventuellement des correctifs pour les problèmes avant que la prochaine version ne soit prête.

Développement principal

Votre stratégie de branchement détermine exactement comment vous utiliserez les outils qui vous sont fournis. Il existe de nombreuses stratégies de création de branches conçues pour différents types d’équipes.

Le développement basé sur l’autoroute est proche de ce que la programmation d’équipe devrait être – une itération rapide dans une master branche pour lancer rapidement un produit viable. L’équipe crée des branches de fonctionnalités de courte durée, qui ne durent généralement pas plus de quelques jours, et s’engage souvent directement sur master.

C’est ce qu’on appelle un «tronc» car il master fait de la branche la branche la plus active et la plus utile de tout le référentiel, comme un tronc d’arbre épais supportant tout le reste. Tout le développement est concentré sur cette branche, qui est facile et rapide à apprendre, offrant une bonne expérience de développeur.

Une fois prête pour la publication, une nouvelle branche versionnée est créée pour chaque version. Cela sépare les versions masteret vous aide également à ajouter ou à sélectionner des correctifs pour les versions LTS.

Cela présente de nombreux avantages, en particulier pour les petites équipes. Si vous travaillez avec quelques développeurs expérimentés que vous connaissez et faites confiance aux autorisations d’écriture de l’ensemble du référentiel, l’intégration de vos modifications dès que possible peut vraiment accélérer le développement. En fin de compte, cela élimine presque toute la bureaucratie associée aux demandes d’extraction et aux fusions constantes, bien qu’une simple communication avec votre équipe soit toujours nécessaire pour se tenir au courant et que vous sachiez toujours sur quoi l’autre travaille.

Cependant, ce n’est pas une bonne organisation car cela dépend de la discipline et des bons développeurs. C’est vraiment génial pour sortir rapidement des produits ou itérer rapidement sur des projets existants, mais dès que vous ajoutez plus de développeurs juniors au projet ou que vous obtenez plus de collaborateurs open source, cela commence à montrer ses défauts.

Flux Git traditionnel

« Git Flow » est un workflow qui fonctionne dans de nombreuses équipes. C’est plus complexe que le workflow de développement de backbone simple, mais il offre de nombreux avantages pour les projets open source et les grands projets avec de nombreux membres d’équipe.

Dans la stratégie de création de branches Git Flow, les branches de fonctionnalités durent plus longtemps et sont au centre de l’intégration quotidienne. Les équipes travailleront sur les fonctionnalités jusqu’à ce qu’elles soient prêtes pour la production, puis passeront par un processus de demande d’extraction pour obtenir leur approbation. Il peut y avoir n’importe quel nombre de fonctionnalités en même temps, y compris celles qui durent suffisamment longtemps pour qu’elles aient besoin d’être rebasées sur des master commits plus récents.

Avec Git Flow, l’accès est plus limité, car la plupart des développeurs n’auront pas l’autorisation de fusionner directement avec develop, et certainement pas avec master, et devront créer des branches comme méthode principale pour apporter des modifications.

Git Flow laisse naturellement du temps pour une révision appropriée du code pendant le processus de demande d’extraction. Cela permet de gérer les conflits avec les relations publiques, les rebases et les fusions plutôt qu’avec une branche dorsale en constante évolution. Cela a du sens pour l’open source car ces forks peuvent provenir de tiers, mais cela a également du sens dans les grands environnements d’équipe ou pour les équipes développant des produits monolithiques avec de nombreux composants.

L’une des principales fonctionnalités de ce flux de travail est le modèle de version. Quand vient le temps d’une nouvelle version, une branche distincte est créée pour la préparation. Les corrections de bogues et les correctifs finaux sont faits ici, puis poussés dans la master branche réelle et reçoivent une balise à partir de laquelle construire la version.

La principale différence est que cette master branche est maintenue avec develop. Les validations des branches de publication sont fusionnées dans develop, ainsi que tous les correctifs. Cela fait toujours develop la branche la plus récente à partir de laquelle les versions sont faites lorsqu’elles sont stables.

Cette séparation facilite la gestion des correctifs de bogues mineurs qui doivent être publiés avant d’être master fusionnés dans les dernières versions. La branche de version fonctionne à peu près de la même manière que la branche de fonctionnalité, avec l’avantage supplémentaire d’être marquée comme stable.

Bien sûr, les demandes constantes d’extraction, de rebase et de fusion sont un travail difficile et peuvent être fastidieuses si vous essayez d’être rapide. Mais tout comme le typage statique ou les tests unitaires, cela vaut la peine de garder les choses organisées et de fonctionner correctement à la fin.

Choisissez ce qui vous convient

En fin de compte, il s’agit d’une bonne étiquette d’équipe, et votre équipe peut très bien s’en sortir avec un historique Git qui ressemble plus à une ligne qu’à un diagramme fantaisiste. Si votre projet est petit ou si vous êtes un amateur solo, respecter les normes strictes de Git peut vous faire plus de mal que de bien.

Mais si vous rencontrez des problèmes avec Git, vous pouvez essayer le développement backbone ou Git Flow. À tout le moins, comprendre l’organisation de votre référentiel vous aidera à améliorer le processus d’intégration.