Provoquer des dégâts par inadvertance avec Git peut être trop facile. Pourtant, la meilleure façon d'utiliser Aller sera toujours controversé.

C'est parce que Git lui-même ne détaille que les opérations de branchement de base, ce qui laisse ses modèles d'utilisation, c'est-à-dire les modèles de branchement, une question d'opinion de l'utilisateur. Les modèles de branchement Git promettent de soulager la douleur en organisant le chaos qui survient inévitablement lorsque les développeurs de logiciels apportent des modifications à leurs bases de code.

Comme beaucoup de développeurs, vous vouliez quelque chose qui «fonctionnerait» afin de pouvoir continuer le développement de logiciels. Alors tu as ramassé Flux Git , un modèle de branchement souvent recommandé aux utilisateurs de Git. Peut-être que vous étiez à bord avec la logique de Git flow au début, jusqu'à ce que vous rencontriez des difficultés avec elle dans la pratique. Ou peut-être que Git flow ne vous semble pas assez adapté pour que vous l'adoptiez. Après tout, il y a d'innombrables variables en jeu, et aucun modèle de branchement ne fonctionnera bien dans toutes les situations.

Bonnes nouvelles! Une variante du modèle de flux Git classique, flux Git amélioré simplifie les manœuvres les plus courantes du flux de travail Git tout en conservant les principaux avantages.

La splendeur et la misère du modèle classique de Git Flow

Je suis un fervent défenseur de Git flow depuis que j'ai découvert à quel point il excelle dans le développement d'un produit qui évolue en incréments de valeur significatifs (en d'autres termes, communiqués ).

Un incrément de valeur significatif nécessite un temps considérable, comme les sprints de plus de deux semaines généralement utilisés dans Scrum développement basé sur. Si une équipe de développement a déjà déployé en production, il peut y avoir des problèmes si la portée de la prochaine version s'accumule au même endroit où réside le code de production, par exemple, dans la branche principale du dépôt Git qu'ils utilisent.

Alors que le produit est encore dans la phase de développement initiale, c'est-à-dire qu'il n'y a pas de production et qu'il n'y a pas de véritables utilisateurs du produit, il est normal que l'équipe garde tout simplement dans la branche principale. En fait, c’est plus que correct: cette stratégie permet le rythme de développement le plus rapide sans trop de cérémonie. Mais les choses changent dans un environnement de production; alors, de vraies personnes commencent à compter sur la stabilité du produit.

Par exemple, s'il y a un bogue critique en production qui doit être corrigé immédiatement, ce serait un désastre majeur pour l'équipe de développement de devoir annuler tout le travail accumulé dans la branche principale jusqu'à présent juste pour déployer le correctif. Et le déploiement de code sans tests appropriés - que le code soit considéré comme à moitié cuit ou bien développé - n'est clairement pas une option.

C’est là que les modèles de branchement brillent, y compris le flux Git. Tout modèle de branchement sophistiqué doit répondre aux questions sur la façon de isoler la prochaine version de la version du système actuellement utilisée par les gens, comment mise à jour cette version avec la prochaine version, et comment introduire des correctifs de tous les bogues critiques de la version actuelle.

Le processus de flux Git répond à ces scénarios fondamentaux en séparant «main» (la branche de production ou «version actuelle») et «develop» (la branche de développement ou de «prochaine version») et en fournissant toutes les règles sur l'utilisation des branches fonctionnalité / version / correctif . Il résout efficacement de nombreux maux de tête liés aux flux de travail de développement de produits basés sur des versions.

comment maîtriser c++

Mais même avec des projets bien adaptés au modèle de flux Git classique, j'ai souffert des problèmes typiques que cela peut entraîner:

• Le flux Git est complexe, avec deux branches de longue durée, trois types de branches temporaires et des règles strictes sur la façon dont les branches interagissent. Une telle complexité rend les erreurs plus probables et augmente l'effort requis pour les corriger.
• Les branches Release et Hotfix nécessitent une «double fusion» - une fois dans main, puis dans develop. Parfois, vous pouvez oublier de faire les deux. Vous pouvez faciliter le branchement de flux Git avec des scripts ou des plugins clients VCS GUI, mais vous devez d'abord les configurer pour chaque machine de chaque développeur impliqué dans un projet donné.
• Dans les flux de travail CI / CD, vous vous retrouvez généralement avec deux versions finales pour une version - une de la dernière validation de la branche de publication elle-même et une autre de la validation de fusion vers main. À proprement parler, vous devez utiliser celui du principal, mais les deux sont généralement identiques, ce qui crée un risque de confusion.

Entrez 'Enhanced Git Flow'

La première fois que j'ai utilisé un flux Git amélioré, c'était sur un nouveau projet de source fermée. Je travaillais avec un autre développeur, et nous avions travaillé sur le projet en nous engageant directement dans la branche principale.

Remarque: jusqu'à la première version publique d'un produit, il est absolument logique de valider toutes les modifications directement dans la branche principale, même si vous êtes un partisan du flux Git, pour des raisons de rapidité et de simplicité du flux de travail de développement. Puisqu'il n'y a pas encore de production, il n'y a aucune possibilité de bogue de production que l'équipe doit corriger dès que possible. Faire toute la magie de branchement qu'implique le flux Git classique est donc excessif à ce stade.

Ensuite, nous nous sommes rapprochés de la version initiale et nous avons convenu qu'au-delà de ce point, nous ne serions plus à l'aise de nous engager directement dans la branche principale. Nous avions évolué assez rapidement et les priorités commerciales ne laissaient pas beaucoup de place pour établir un processus de développement solide comme le roc, c'est-à-dire un processus avec suffisamment de tests automatisés pour nous donner l'assurance que notre branche principale était prête à être lancée.

Cela semblait être un cas valable pour le modèle de flux Git classique. Avec des branches principales et de développement séparées et suffisamment de temps entre des incréments de valeur significatifs, on était convaincu que le contrôle qualité manuel donnerait des résultats suffisamment bons. Quand j'ai préconisé Git flow, mon collègue a suggéré quelque chose de similaire, mais avec quelques différences clés.

Au début, j'ai repoussé. Il me semblait que certains des «correctifs» proposés pour le flux Git classique étaient un peu trop révolutionnaires. Je pensais qu'ils pourraient briser l'idée principale et que l'approche dans son ensemble échouerait. Mais avec un peu plus de réflexion, j'ai réalisé que ces ajustements ne cassent pas réellement le flux de Git. Pendant ce temps, ils en font un meilleur modèle de branchement Git en résolvant tous les problèmes mentionnés ci-dessus.

Après avoir réussi avec l'approche modifiée dans ce projet, je l'ai utilisée dans un autre projet à code source fermé avec une petite équipe derrière, où j'étais le propriétaire permanent de la base de code et un développeur externalisé ou deux aidaient de temps en temps. Sur ce projet, nous sommes passés à la production six mois plus tard, et depuis, nous utilisons les tests CI et E2E depuis plus d'un an, avec des sorties tous les mois environ.

comment faire une simulation de monte carlo

Mon expérience globale avec cette nouvelle approche de branchement était si positive que je voulais la partager avec mes collègues développeurs pour les aider à contourner les inconvénients du flux Git classique.

Similitudes avec Classic Git Flow: isolation du développement

Pour l'isolement du travail dans un flux Git amélioré, il existe toujours deux branches à longue durée de vie, principale et develop. (Les utilisateurs ont toujours des fonctionnalités de correctif et de version - avec un accent sur les «capacités», car il ne s'agit plus de branches. Nous entrerons dans les détails dans la section des différences.)

Il n’existe pas de schéma de dénomination officiel pour les branches de fonctionnalités de flux Git classiques. Vous venez de vous séparer du développement et de le fusionner pour le développement lorsque la fonctionnalité est prête. Les équipes peuvent utiliser n'importe quelle convention de dénomination de leur choix ou espérer simplement que les développeurs utiliseront des noms plus descriptifs que 'ma branche'. La même chose est vraie pour le flux Git amélioré.

Toutes les fonctionnalités accumulées dans la branche de développement jusqu'à un certain point de coupure façonneront la nouvelle version.

Fusion de squash

J'ai fortement recommandé d'utiliser squash merge pour les branches de fonctionnalités afin de garder un historique agréable et linéaire la plupart du temps. Sans cela, les graphes de validation (à partir d'outils GUI ou git log --graph) commencent à paraître bâclés lorsqu'une équipe jongle avec même une poignée de branches de fonctionnalités:

Mais même si vous êtes d'accord avec les visuels de ce scénario, il y a une autre raison d'écraser. Sans écraser, validez les vues d'historique - parmi elles toutes les deux git log (sans --graph) et aussi GitHub - racontez des histoires plutôt incohérentes même avec le plus simple des scénarios de fusion:

comment activer le bot discord

La mise en garde à l'utilisation de la fusion squash est que l'historique de la branche de fonctionnalité d'origine est perdu. Mais cette mise en garde ne s'applique même pas si vous utilisez GitHub, par exemple, qui expose l'histoire originale complète d'une branche de fonctionnalité via la demande d'extraction qui a été fusionnée, même après la suppression de la branche de fonctionnalité elle-même.

Différences par rapport à Git Flow classique: versions et correctifs

Passons en revue le cycle de publication car (espérons-le) c'est la principale chose que vous ferez. Lorsque nous arrivons au point où nous aimerions publier ce qui s'est accumulé en développement, il s'agit strictement d'un sur-ensemble de main. C'est ensuite là que commencent les plus grandes différences entre le flux Git classique et amélioré.

Versions dans Enhanced Git Flow

Chaque étape de création d'une version avec un flux Git amélioré diffère du processus de flux Git classique:

1. Les versions sont basées sur le principal plutôt que sur le développement. Marquer la pointe actuelle de la branche principale avec quelque chose de significatif. J'ai adopté des balises basées sur la date du jour au format ISO 8601 précédées d'un «v» - par exemple, v2020-09-09 .
   • S'il y avait plusieurs versions dans une journée (par exemple, des correctifs à chaud), le format pourrait avoir un numéro ou une lettre séquentielle ajouté au besoin.
   • Sachez que les balises ne correspondent généralement pas aux dates de sortie. Ils sont uniquement destinés à forcer Git à garder une référence sur l'apparence de la branche principale au moment où le prochain processus de publication a commencé.
2. Poussez le tag en utilisant git push origin .
3. Après cela, un peu de surprise: supprimer votre succursale principale locale . Ne vous inquiétez pas, car nous allons le restaurer sous peu.
   • Tous les commits vers main sont toujours sûrs - nous les avons protégés du garbage collection en marquant main à l'étape précédente. Chacun de ces commits, même les correctifs, comme nous le verrons bientôt, fait également partie du développement.
   • Assurez-vous simplement qu'une seule personne dans une équipe le fait pour une version donnée; c’est ce que l’on appelle le rôle de «gestionnaire de publication». Un responsable de publication est généralement le membre de l'équipe le plus expérimenté et / ou le plus senior, mais une équipe serait sage d'éviter qu'un membre de l'équipe en particulier n'assume ce rôle de manière permanente. Il est plus logique de diffuser les connaissances au sein de l'équipe pour augmenter le tristement célèbre facteur de bus .
4. Créez une nouvelle branche principale locale à la fin de la validation de votre branche de développement .
5. Poussez cette nouvelle structure en utilisant git push --force , puisque le repo distant n'acceptera pas un tel «changement radical» si facilement. Encore une fois, ce n'est pas aussi dangereux que cela puisse paraître dans ce contexte car:
   • Nous déplaçons simplement le pointeur de la branche principale d'un commit à un autre.
   • Un seul membre de l'équipe en particulier effectue ce changement à la fois.
   • Le travail de développement quotidien se déroule dans la branche de développement, de sorte que vous ne perturberez le travail de personne en déplaçant Main de cette façon.
6. Vous avez votre nouvelle version! Déployez-le dans l'environnement de test et testez-le. (Nous allons discuter des modèles CI / CD pratiques ci-dessous.) Tous les correctifs vont directement à la branche principale, et celle-ci commencera à diverger de la branche de développement à cause de cela.
   • En même temps, vous pouvez commencer à travailler sur une nouvelle version dans la branche de développement, le même avantage vu dans le flux Git classique.
   • Dans le cas malheureux où un correctif est nécessaire pour ce qui est actuellement en production (et non pour la prochaine version en préparation) à ce stade, vous trouverez plus de détails sur ce scénario dans «Gestion des correctifs pendant une version active…» ci-dessous.
7. Lorsque votre nouvelle version est considérée comme suffisamment stable, déployer la version finale dans l'environnement de production et faire une seule fusion de squash de main pour développer pour récupérer tous les correctifs.

Correctifs dans Enhanced Git Flow

Les boîtiers Hotfix sont doubles. Si vous effectuez un correctif lorsqu'il n'y a pas de version active - c'est-à-dire que l'équipe prépare une nouvelle version dans la branche de développement - c'est un jeu d'enfant: engagez-vous sur la main, faites déployer et tester vos modifications en préparation jusqu'à ce qu'elles soient prêtes, puis déployez en production.

à quoi ressemble c++

En guise de dernière étape, choisissez votre commit de main à développer pour vous assurer que la prochaine version contiendra tous les correctifs. Dans le cas où vous vous retrouverez avec plusieurs validations de correctifs, vous économisez des efforts, surtout si votre IDE ou un autre outil Git peut le faciliter, en créant et en appliquant un correctif au lieu de sélectionner plusieurs fois. Essayer d'écraser la fusion main pour développer après la version initiale risque de se traduire par des conflits avec les progrès indépendants réalisés dans la branche de développement, donc je ne le recommande pas.

Gérer les correctifs lors d'une version active - c'est-à-dire, lorsque vous forcez simplement le push main et que vous êtes encore en train de préparer la nouvelle version - est la partie la plus faible du flux Git amélioré. En fonction de la durée de votre cycle de publication et de la gravité du problème que vous devez résoudre, essayez toujours d'inclure des correctifs dans la nouvelle version elle-même. C'est la façon la plus simple de procéder et ne perturbera pas du tout le flux de travail global.

Dans le cas où cela ne serait pas possible - vous devez introduire un correctif rapidement et vous ne pouvez pas attendre que la nouvelle version soit prête - alors préparez-vous pour une procédure Git quelque peu complexe:

1. Créez une branche - nous l'appellerons 'nouvelle version', mais votre équipe peut adopter n'importe quelle convention de dénomination ici - avec le même commit que l'astuce actuelle de main. Poussez la nouvelle version.
2. Supprimez et recréez la branche principale locale lors de la validation de la balise que vous avez créée précédemment pour la version active actuelle. Forcer la poussée principale.
3. Introduisez les correctifs nécessaires pour la main, le déploiement dans l'environnement de test et le test. Dès que cela est prêt, déployez-le en production.
4. Propagez les modifications de la version principale actuelle vers la nouvelle version via une sélection de cerises ou un correctif.
5. Après cela, recommencez la procédure de libération: marquez la pointe du main actuel et poussez la balise, supprimez et recréez le principal local à la pointe de la branche de la nouvelle version et forcez le push main.
   1. Vous n'aurez probablement pas besoin de la balise précédente, vous pouvez donc la supprimer.
   2. La branche de la nouvelle version est désormais redondante, vous pouvez donc la supprimer également.
6. Vous devriez maintenant être prêt à partir comme d'habitude avec une nouvelle version. Terminez en propageant les correctifs d'urgence de main à développement via le cherry-picking ou un patch.

Avec une planification adéquate, une qualité de code suffisamment élevée et une culture de développement et d'assurance qualité saines, il est peu probable que votre équipe doive utiliser cette méthode. Il était prudent de développer et de tester un tel plan d'urgence pour un flux Git amélioré, au cas où, mais je n'ai jamais eu besoin de l'utiliser dans la pratique.

Configuration CI / CD au-dessus de Git Flow amélioré

Tous les projets ne nécessitent pas un environnement de développement dédié. Il peut être assez facile de configurer un environnement de développement local sophistiqué sur chaque machine de développement.

Mais un environnement de développement dédié peut contribuer à une culture de développement plus saine. L'exécution de tests, la mesure de la couverture des tests et le calcul des métriques de complexité sur la branche de développement réduisent souvent le coût des erreurs en les rattrapant bien avant qu'elles ne se terminent en staging.

J'ai trouvé que certains modèles CI / CD étaient particulièrement utiles lorsqu'ils sont combinés avec un flux Git amélioré:

• Si vous avez besoin d'un environnement de développement, configurez CI pour créer, tester et déployer dessus à chaque validation dans la branche de développement. Intégrez les tests E2E ici également, si vous l'avez et si cela a du sens dans votre cas.
• Configurez CI pour générer, tester et déployer dans l'environnement intermédiaire à chaque validation dans la branche principale. Les tests E2E sont également très bénéfiques à ce stade.
  • Il peut sembler redondant d’utiliser les tests E2E aux deux endroits, mais rappelez-vous que les correctifs ne se produiront pas en développement. Le déclenchement d'E2E sur les validations vers main testera les correctifs et les changements quotidiens avant qu'ils ne sortent, mais aussi le déclenchement sur les commits à développer attrapera les bogues plus tôt.
• Configurez CI de manière à permettre à votre équipe de déployer des builds de l'environnement principal vers l'environnement de production sur demande manuelle.

Ces modèles sont relativement simples, mais fournissent des machines puissantes pour soutenir les opérations de développement quotidiennes.

comment devenir coach agile

Le modèle Git Flow amélioré: améliorations et limitations possibles

Le flux Git amélioré n'est pas pour tout le monde. Il tire parti de la tactique controversée de la force poussant la branche principale, de sorte que les puristes peuvent lui en vouloir. D'un point de vue pratique, il n'y a rien de mal à cela.

Comme mentionné, les correctifs sont plus difficiles lors d'une version mais toujours possibles. Avec une attention appropriée accordée au contrôle qualité, à la couverture des tests, etc., cela ne devrait pas arriver trop souvent, donc de mon point de vue, c'est un compromis valable pour les avantages globaux d'un flux Git amélioré par rapport au flux Git classique. Je serais très intéressé de savoir comment les tarifs de flux Git améliorés dans les équipes plus importantes et avec des projets plus complexes, où les correctifs peuvent être plus fréquents.

Mon expérience positive avec le modèle de flux Git amélioré tourne également principalement autour de projets commerciaux à source fermée. Cela peut être problématique pour un projet open-source où les pull-requests sont souvent basés sur une ancienne version dérivée de l'arborescence source. Il n'y a pas d'obstacles techniques pour résoudre ce problème - cela pourrait simplement exiger plus d'efforts que prévu. J'apprécie les commentaires des lecteurs ayant beaucoup d'expérience dans l'espace open source concernant l'applicabilité du flux Git amélioré dans de tels cas.

Remerciements particuliers au collègue d'ApeeScape Antoine Pham pour son rôle clé dans le développement de l'idée derrière l'amélioration du flux Git.

---

Lectures complémentaires sur le blog d'ingénierie ApeeScape:

• Développement basé sur le tronc et Git Flow
• Workflows Git pour les pros: un bon guide Git

---

As a Partenaire Microsoft Gold , ApeeScape est votre réseau d'élite d'experts Microsoft. Construisez des équipes hautement performantes avec les experts dont vous avez besoin - n'importe où et exactement quand vous en avez besoin!

Comprendre les bases

Qu'est-ce que Git Flow?

Git flow est un modèle de branchement pour le système de contrôle de version (VCS) Git. Un modèle de branchement s'appuie sur des opérations Git de base, prescrivant des modèles d'utilisation destinés à permettre une gestion robuste des versions. Git flow a été annoncé publiquement dans un article de blog de Vincent Driessen en 2010 et est resté populaire depuis.

Quelle est la stratégie de branchement de flux Git?

La stratégie de branchement de flux Git excelle lors du développement d'un produit qui évolue par incréments de valeur significatifs. Il le fait en séparant «main» (la branche de production ou «version actuelle») et «develop» (la branche de développement ou de «prochaine version») et en fournissant toutes les règles nécessaires sur l'utilisation des branches d'assistance.

Comment utiliser Git Flow?

Vous utilisez Git flow en suivant son modèle prescrit. Cela permet à votre équipe d'obtenir des réponses aux questions sur la façon d'isoler la prochaine version de la version du système actuellement en production, comment mettre à jour cette version avec la prochaine version et comment introduire des correctifs de tous les bogues critiques dans la version actuelle.

Dois-je utiliser Git flow?

Le fait d'utiliser ou non Git flow dépend de votre projet particulier. La principale question à laquelle il faut répondre est: «Le flux de travail de développement global a-t-il une assurance qualité automatique suffisante pour maintenir la branche principale en état de sortie?» Si la réponse est non, un tel projet bénéficiera probablement du flux Git.

Quel est le meilleur workflow Git?

Il n'y a pas de meilleur flux de travail Git, car la réponse dépend du contexte particulier du projet. Certains projets bénéficieront du flux Git ou d'une variante de celui-ci, tandis que d'autres seront meilleurs avec une approche de développement basée sur le tronc.