Travail d'équipe sans confusion : comprendre les stratégies de branchement dans Git

Introduction

Git est devenu de facto la norme industrielle en matière de contrôle de version dans la création de logiciels. Pour savoir ce qu'est git et comment démarrer, lisez d'abord mon article à ce sujet. L'avez-vous lu ? Super, passons à autre chose ! Qu'on le veuille ou non, l'instrument créé par Linus Towalds ne va pas prendre sa retraite. Par conséquent, il est logique de parler de la façon dont les équipes distribuées fonctionnent dans git et de la stratégie de branchement à choisir pour cela. Et ce n’est pas du tout une question oiseuse. Souvent, dans une situation où une nouvelle équipe de développeurs qui n'ont pas collaboré entre eux est constituée, la stratégie de branchement est l'une des premières choses à décider. Et il y aura des gens qui écumeront pour prouver qu’une stratégie est meilleure qu’une autre. Par conséquent, je souhaite vous transmettre des informations sur ce qu'ils sont généralement.

Des stratégies de branchement sont-elles nécessaires ?

Mais ils sont nécessaires, et ils le sont toujours. Parce que si vous n'êtes pas d'accord sur quelque chose dans l'équipe, il s'avère que chacun fera ce qu'il veut :

• travailler dans la branche dans laquelle il souhaite ;
• fusionner dans d'autres branches qu'il souhaite ;
• supprimer certaines branches ;
• en créer de nouveaux ;
• et ainsi de suite : chacun des membres de l’équipe est dans un flux incontrôlé.

Par conséquent, vous trouverez ci-dessous trois stratégies. Aller!

Stratégie GitHub Flow

La stratégie de branchement, aussi étrange soit-elle, est préférée dans GitHub :) Un ensemble de règles qui doivent être suivies y est attaché :

1. Le code de la branche master doit être ininterrompu et prêt à être déployé à tout moment (c'est-à-dire que vous ne pouvez pas y mettre de code qui vous empêcherait de construire le projet et de le déployer sur le serveur).
2. Lorsque vous envisagez de travailler sur une nouvelle fonctionnalité, vous devez créer une nouvelle branche (branche de fonctionnalité) basée sur la branche principale et lui donner un nom significatif. Validez votre code localement et transférez régulièrement vos modifications vers la même branche dans un référentiel distant.
3. Ouvrez une Pull-Request (vous pouvez lire ce qu'est une pull-request ici ) lorsqu'il y a un sentiment clair que le travail est prêt et peut être fusionné dans la branche principale (ou si vous n'êtes pas sûr, mais souhaitez obtenir des commentaires sur le travail effectué).
4. Une fois qu'une nouvelle fonctionnalité d'une pull request a été approuvée, elle peut être fusionnée dans la branche principale.
5. Lorsque les modifications sont fusionnées dans la branche principale, elles doivent être immédiatement déployées sur le serveur.

Selon GitHub Flow, il s'avère qu'avant de commencer à travailler sur quelque chose de nouveau, qu'il s'agisse d'un correctif ou d'une nouvelle fonctionnalité, vous devez créer une nouvelle branche basée sur master et lui donner un nom approprié. Ensuite, le travail de mise en œuvre commence. Vous devez constamment envoyer des commits vers un serveur distant portant le même nom. Lorsque vous comprenez que tout est prêt, vous devez créer une pull request dans la branche master. Ensuite, au moins une, ou mieux encore, deux personnes devraient regarder ce code et cliquer sur Approuver. Habituellement, le chef d'équipe du projet et quelqu'un d'autre doivent l'examiner, puis vous pouvez compléter la pull request. GitHub Flow est également connu pour piloter la livraison continue (CD) sur un projet. Car lorsque des modifications sont apportées à la branche principale, elles doivent immédiatement être déployées sur le serveur.

Stratégie GitFlow

La stratégie précédente (GitHub Flow) n’était essentiellement pas très complexe. Il existe deux types de branches : les branches principales et les branches de fonctionnalités. Mais GitFlow est plus sérieux. Au moins d'après l'image ci-dessus, vous pouvez comprendre ceci.) Alors, comment fonctionne cette stratégie ? En général, GitFlow se compose de deux branches permanentes et de plusieurs types de branches temporaires (Dans le contexte de GitHub Flow, la branche principale est permanente et les autres sont temporaires). Succursales permanentes :

• maître : personne ne doit toucher cette branche ni y pousser quoi que ce soit. Dans cette stratégie, master affiche la dernière version stable utilisée en production (c'est-à-dire sur le serveur réel) ;
• le développement est la branche du développement. Cela pourrait potentiellement être instable.

Le développement s'effectue à l'aide de trois branches temporaires auxiliaires :

1. Branches de fonctionnalités - pour développer de nouvelles fonctionnalités.
2. Branches de publication - pour préparer la sortie d'une nouvelle version du projet.
3. Les branches Hotfix sont une solution rapide à un défaut déjà trouvé par de vrais utilisateurs sur un vrai serveur.

Branches de fonctionnalités

Les branches de fonctionnalités sont créées par les développeurs pour de nouvelles fonctionnalités. Ils doivent toujours être créés sur la base de la branche de développement. Après avoir terminé le travail sur la nouvelle fonctionnalité, vous devez créer une pull request dans la branche de développement. Il est clair que dans les grandes équipes, il peut y avoir plusieurs branches de fonctionnalités à la fois. Encore une fois, faites attention à l'image au début de la description de la stratégie GitFlow.

Libérer les branches

Lorsque le nombre requis de nouvelles fonctionnalités a été préparé dans la branche de développement, vous pouvez vous préparer à publier une nouvelle version du produit. La branche release nous aidera avec cela. qui est créé sur la base de la branche de développement. Lorsque vous travaillez avec la branche release, vous devez rechercher et corriger tous les défauts. Toutes les nouvelles modifications nécessaires pour stabiliser la branche de publication doivent également être réintégrées dans le développement. Ceci est fait afin de stabiliser et de développer la branche. Lorsque les testeurs disent que la branche est suffisamment stable pour une nouvelle version, elle est fusionnée dans la branche master. Ensuite, une balise est créée sur ce commit (balise : vous pouvez en savoir plus ici ), à laquelle est attribué un numéro de version. A titre d'exemple, vous pouvez regarder l'image au début de la stratégie. Ainsi, Tag 1.0 n'est qu'une étiquette qui indique la version 1.0 du projet. Et la dernière chose est un correctif de branche.

Branches de correctifs

Les branches Hotfix sont également destinées à la sortie d'une nouvelle version en master. La seule différence est que cette sortie n'est pas prévue. Il existe des situations où des défauts parviennent à être libérés et sont déjà découverts en production. Par exemple, iOS : dès qu'ils publient une nouvelle version, vous recevez immédiatement un certain nombre de mises à jour avec des correctifs pour les défauts découverts après la sortie. À cet égard, il est nécessaire de corriger rapidement ce défaut et de publier une nouvelle version. Sur notre image, cela correspond à la version 1.0.1. L'idée est que le travail sur de nouvelles fonctionnalités ne peut pas s'arrêter aux moments où vous devez corriger un défaut sur un serveur réel (comme on dit, « en production » : encore une fois, une copie du mot anglais production). La branche du correctif doit être créée à partir de la branche principale, car elle représente l'état qui fonctionne en production. Dès que la solution au défaut est prête, elle est fusionnée avec le maître et une nouvelle étiquette est créée. Tout comme la préparation d'une branche de publication, une branche de correctif doit fusionner sa solution dans la branche de développement.

La stratégie Forking Workflow

Dans le cadre de la stratégie Forking Workflow, le développement s'effectue de telle manière qu'il existe deux référentiels :

1. Le référentiel d'origine dans lequel toutes les modifications seront fusionnées.
2. Un référentiel fork (il s'agit d'une copie du référentiel d'origine en possession d'un autre développeur qui souhaite apporter des modifications à l'original).

Cela semble un peu étrange jusqu’à présent, n’est-ce pas ? Pour ceux qui ont déjà rencontré le développement open source, cette approche est déjà familière. Cette stratégie offre l'avantage suivant : le développement peut être effectué dans un référentiel fork sans accorder de droits de développement conjoint dans celui d'origine. Bien entendu, le propriétaire du référentiel d'origine a le droit de rejeter les modifications proposées. Ou acceptez et tuez-les. Ceci est pratique à la fois pour le propriétaire du référentiel d'origine et pour le développeur qui souhaite participer à la création d'un produit. Par exemple, vous pouvez proposer des modifications au noyau Linux . Si Linus décide que cela a du sens, les modifications seront ajoutées (!!!).

L'exemple de workflow de forking

Le Forking Flow est utilisé sur GitHub lorsque vous souhaitez utiliser une bibliothèque. Il présente un défaut qui empêche son utilisation complète. Disons que vous avez suffisamment approfondi le problème et que vous connaissez la solution. Grâce à la stratégie The Forking Workflow, vous pouvez résoudre ce problème sans accorder le droit de travailler dans le référentiel de bibliothèque d'origine. Pour commencer, vous devez sélectionner un référentiel, par exemple le noyau Spring Framework . Recherchez le bouton Fork dans le coin supérieur droit et cliquez dessus : cela prendra un certain temps, après quoi une copie de ce référentiel original apparaîtra dans votre compte personnel, qui indiquera qu'il s'agit d'un fork : Vous pourrez ensuite travailler avec ce dépôt comme d'habitude, ajouter des modifications à la branche principale et quand tout sera prêt, créer une Pull-Request vers le dépôt d'origine. Pour ce faire, cliquez sur le bouton Nouvelle demande de tirage :

Quelle stratégie choisir

Git est un outil flexible et puissant qui vous permet de travailler en utilisant un large éventail de processus et de stratégies. Mais plus le choix est vaste, plus il est difficile de décider quelle stratégie choisir maintenant. De toute évidence, il n’existe pas de réponse universelle. Cela dépend complètement de la situation. Cependant, quelques recommandations peuvent vous aider :

1. Il est préférable de choisir d’abord la stratégie la plus simple. Passez à des stratégies plus complexes uniquement lorsque cela est nécessaire.
2. Envisagez des stratégies comportant le moins de types de branches de développeurs possible.
3. Examinez les avantages et les inconvénients des différentes stratégies et, en fonction du projet, choisissez la bonne.

C'est tout ce que je voulais vous dire sur la stratégie de branchement dans git. Merci de votre attention :) Abonnez-vous à mon compte GitHub , j'y publie souvent mon travail dans diverses technologies et outils que j'utilise dans mon travail

Liens utiles

• Flux GitHub : la meilleure façon d'utiliser Git et GitHub
• Pull request sur GitHub ou Comment puis-je apporter des modifications au projet de quelqu'un d'autre
• GitHub : à propos des demandes d'extraction
• Intégration continue, livraison et déploiement différenciés
• Bases de Git : Travailler avec des balises
• Habr : modèle de branchement réussi pour Git