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

Git est un 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 facile à suivre qui fonctionne pour votre entreprise pour un développement rapide.

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

Avec la montée en puissance de pipelines d’automatisation faciles à utiliser comme Jenkins, de nombreuses entreprises commencent à faire de l’intégration et de la livraison continues (CI/CD), les modifications apportées par les développeurs étant souvent fusionnées dans le référentiel, expédiant généralement un produit une fois par semaine plutôt que horaire mensuel.

Ce type de vitesse met beaucoup de stress sur votre organisation, en particulier en ce qui concerne Git. Si vous avez 50 personnes essayant toutes d’apporter des modifications à la même master branche, vous allez rencontrer 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, à tout le moins, à vous et à vos coéquipiers, de perdre du temps à rechercher d’autres problèmes Git sur Google.

Présenter et développer des succursales

Il y a deux gros problèmes que les branches Git doivent aider à résoudre : garder vos équipes internes synchronisées et maintenir votre version publique.

Lorsque vous démarrez une branche dans Git, de nouveaux commits seront effectués sur cette branche, plutôt que master. Cela peut être utile pour suivre les progrès individuels sur une fonctionnalité ou une correction de bogue donnée ; par exemple, chaque branche peut implémenter une fonctionnalité décrite dans un problème dans un service Kanban, comme Jira, Trello ou Github Issues & Projects.

Habituellement, la fusion des branches se fait avec demandes d’extraction, une fonctionnalité des solutions Git hébergées comme Github, où l’équipe demande que master tirer de la feature branche, et intégrer les changements 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 que la succursale fonctionne correctement avant d’être poussée dans la chaîne.

L’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 cela peut être interrompu par un commit errant.

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 pousser une nouvelle version. Cela permet d’effectuer plusieurs commits en arrière-plan, sur la branche de développement entre les versions.

Un autre avantage de ce modèle est de pouvoir effectuer des commits séparés sur la branche de production, fournissant peut-être des correctifs aux problèmes avant que la prochaine version ne soit prête.

Développement basé sur le tronc

Votre stratégie de branchement détermine la manière exacte dont vous utilisez ces outils qui vous sont fournis. Il existe de nombreuses stratégies de branchement conçues pour différents types d’équipes.

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

C’est ce qu’on appelle le « tronc » parce que l’effet de cela rend le master branche la branche la plus active et la plus utile de tout le dépôt, comme un gros tronc d’arbre qui supporte tout le reste. Tout le développement se fait en se concentrant sur cette branche, qui est rapide et facile à comprendre, ce qui permet 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 permet de séparer les versions des masteret 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 une poignée de développeurs seniors que vous connaissez et que vous faites confiance aux autorisations d’écriture sur l’ensemble du référentiel, l’intégration de vos modifications dès que possible peut vraiment accélérer le développement. Après tout, cela supprime presque toute la bureaucratie des demandes d’extraction et des fusions constantes, bien qu’une simple communication avec votre équipe soit toujours nécessaire pour éviter de se marcher sur les pieds, et vous devez savoir à tout moment sur quoi un autre travaille.

Cependant, ce n’est pas une excellente organisation, car elle repose sur la discipline et de bons développeurs pour réussir. C’est vraiment génial pour sortir rapidement des produits ou pour itérer rapidement sur des projets existants, mais une fois que vous ajoutez plus de développeurs juniors au projet ou que vous obtenez plus de collaborateurs open source, cela va commencer à montrer ses défauts.

Flux Git traditionnel

« Git Flow » est un workflow qui a fonctionné pour de nombreuses équipes. C’est plus compliqué que le flux de travail simple du développement basé sur le tronc, mais il offre de nombreux avantages pour les projets open source et les grands projets avec de nombreux membres d’équipe.

Dans une stratégie de création de branches Git Flow, les branches de fonctionnalités ont une durée de vie plus longue et constituent le principal objectif 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 le processus de demande d’extraction pour les faire approuver. Il peut y avoir un certain nombre de fonctionnalités à la fois, y compris celles qui durent assez longtemps pour nécessiter un rebasage sur des fonctionnalités plus récentes. master engage.

Avec Git Flow, l’accès est plus restreint, car la plupart des développeurs n’auront pas la permission de fusionner directement sur developet bien sûr pas sur masteret devra 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. Il permet de gérer les conflits par le biais de relations publiques, de changement de base et de fusion, plutôt que par une branche principale en constante évolution. Cela a du sens pour l’open source, car ces succursales peuvent provenir d’étrangers, mais cela a également du sens dans les grands environnements d’équipe ou pour les équipes fournissant des produits monolithiques avec de nombreux composants.

L’une des principales caractéristiques de ce flux de travail est le modèle de version. Lorsqu’il est temps de publier une nouvelle version, une branche distincte est créée pour se préparer. Les corrections de bogues et les correctifs finaux sont effectués ici, puis poussés vers le réel master branche et donné une étiquette, à partir de laquelle une version peut être construite.

La principale différence est que cela master la branche est maintenue à côté develop. Les commits des branches de publication sont fusionnés dans develop, ainsi que tous les correctifs. Cela fait develop toujours la branche la plus à jour, à partir de laquelle les versions sont créées lorsqu’elles sont stables.

Cette séparation facilite la gestion des correctifs de bogues plus petits qui doivent être publiés avant master est fusionné avec les dernières versions. Une branche de version fonctionne de manière assez similaire à une branche de fonctionnalité, la fonctionnalité étant le fait qu’elle est marquée comme une version stable.

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

Choisissez ce qui vous convient

En fin de compte, il s’agit d’avoir 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, le respect des 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 basé sur le tronc ou Git Flow. À tout le moins, être conscient de l’organisation de votre référentiel vous aidera à améliorer votre processus d’intégration.