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

Introduction

Git est devenu le standard industriel de facto pour les systèmes de contrôle de version dans le développement de logiciels. Vous devriez d'abord lire mon article sur ce qu'est Git et comment commencer. L'avez-vous lu? Excellent, allons-y ! Qu'on le veuille ou non, cet outil créé par Linus Tovalds ne va pas prendre sa retraite. Il est donc logique de parler de la façon dont les équipes distribuées travaillent avec Git et de la stratégie de branchement qu'elles doivent choisir pour cela. Ce n'est pas une question sans conséquence. Lors de la constitution d'une nouvelle équipe de développement qui n'a jamais travaillé ensemble auparavant, la stratégie de ramification est souvent l'une des premières choses à décider. Et certaines personnes auront la mousse à la bouche pour prouver qu'une stratégie est meilleure qu'une autre. Donc, je veux vous transmettre quelques informations générales à leur sujet.

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

Ils sont en effet nécessaires. Très nécessaire. Parce que si l'équipe n'est pas d'accord sur quelque chose, alors chaque membre de l'équipe fera ce qu'il veut :

• travailler dans n'importe quelle branche
• fusionner dans d'autres branches arbitraires
• suppression de certaines branches
• en créer de nouveaux
• et ainsi chaque membre de l'équipe agira dans un flux non géré.

C'est pourquoi nous avons trois stratégies à considérer ci-dessous. Allons-y!

Flux GitHub

Cette stratégie de branchement, curieusement, est préférée sur GitHub :) Elle est accompagnée d'un ensemble de règles :

1. Le code de la branche master ne doit pas être cassé. Il doit être prêt à être déployé à tout moment. Autrement dit, vous ne devez 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 de nouvelles fonctionnalités, vous devez créer une nouvelle branche de fonctionnalité basée sur la branche principale et lui donner un nom significatif. Validez votre code localement et poussez régulièrement vos modifications vers la même branche dans le référentiel distant.
3. Ouvrez une demande d'extraction (vous pouvez en savoir plus sur les demandes d'extraction ici ) lorsque vous pensez 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 la nouvelle fonctionnalité de la demande d'extraction 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 déployées immédiatement sur le serveur.

Selon GitHub Flow, 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 sur la mise en œuvre commence. Vous devez constamment soumettre des commits au serveur distant avec le même nom. Lorsque vous concluez que tout est prêt, vous devez créer une demande d'extraction vers la branche principale. Ensuite, au moins une, ou mieux encore, deux personnes devraient regarder ce code avant de cliquer sur "Approuver". Habituellement, le chef d'équipe du projet et une deuxième personne devraient certainement y jeter un coup d'œil. Ensuite, vous pouvez compléter la demande d'extraction. GitHub Flow est également connu pour piloter la livraison continue (CD) dans les projets. En effet, lorsque les modifications sont apportées à la branche principale, elles doivent être déployées immédiatement sur le serveur.

GitFlow

La stratégie précédente (GitHub Flow) n'est pas très compliquée à la base. Il existe deux types de branches : les branches master et feature. Mais GitFlow est plus sérieux. Au moins, l'image ci-dessus devrait clarifier cela :) Alors, comment cette stratégie fonctionne-t-elle ? En général, GitFlow se compose de deux branches persistantes et de plusieurs types de branches temporaires. Dans le cadre de GitHub Flow, la branche master est persistante et les autres sont temporaires. Branches persistantes

• maître : Personne ne doit toucher ou pousser quoi que ce soit à cette branche. Dans cette stratégie, master représente la dernière version stable, qui est utilisée en production (c'est-à-dire sur un vrai serveur)
• développement : la branche développement. Il pourrait être instable.

Le développement se fait à 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 publication d'une nouvelle version du projet.
3. Branches Hotfix — pour corriger rapidement un bogue trouvé par de vrais utilisateurs sur un vrai serveur.

Fonctionnalités des succursales

Les branches de fonctionnalités sont créées par les développeurs pour de nouvelles fonctionnalités. Ils doivent toujours être créés en fonction de la branche de développement. Après avoir terminé le travail sur la nouvelle fonctionnalité, vous devez créer une demande d'extraction à la branche de développement. De toute évidence, les grandes équipes peuvent avoir plusieurs branches de fonctionnalités à la fois. Revoyez l'image au début de la description de la stratégie GitFlow.

Libérer les branches

Lorsque l'ensemble requis de nouvelles fonctionnalités est prêt dans la branche de développement, vous pouvez vous préparer à la sortie d'une nouvelle version du produit. Une branche de publication, qui est créée sur la base de la branche de développement, nous y aidera. Lorsque vous travaillez avec la branche de publication, vous devez rechercher et corriger tous les bogues. Toute nouvelle modification requise pour stabiliser la branche de publication doit également être fusionnée dans la branche de développement. Ceci est fait afin de stabiliser également la branche de développement. Lorsque les testeurs disent que la branche est suffisamment stable pour une nouvelle version, elle est fusionnée dans la branche master. Plus tard, une balise, à laquelle est attribué un numéro de version, est créée pour ce commit. Pour voir un exemple, regardez l'image au début de la stratégie. Là, vous verrez Tag 1.0— c'est juste une balise qui indique la version 1.0 du projet. Et enfin, nous avons la branche hotfix.

Branches de correctifs

Les branches de correctifs sont également destinées à publier une nouvelle version sur la branche principale. La seule différence est que ces versions ne sont pas prévues. Il existe des situations où des bogues pénètrent dans la version publiée et sont découverts dans l'environnement de production. Prenez iOS : dès qu'une nouvelle version est publiée, vous obtenez immédiatement un tas de mises à jour avec des correctifs pour les bogues qui ont été trouvés après la sortie. En conséquence, nous devons rapidement corriger un bogue et publier une nouvelle version. Dans notre image, cela correspond à la version 1.0.1. L'idée est que le travail sur de nouvelles fonctionnalités ne doit pas s'arrêter lorsqu'il est nécessaire de corriger un bogue sur un vrai serveur (ou comme on dit, "en prod" ou "en production"). La branche de correctif doit être créée à partir de la branche principale, car elle représente ce qui est actuellement en cours d'exécution en production. Dès que la correction du bug est prête, il est fusionné dans master et une nouvelle balise est créée. Tout comme la préparation d'une branche de publication, une branche de correctif doit également fusionner son correctif dans la branche de développement.

Flux de travail de bifurcation

Dans le workflow de fork, le développement implique 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, détenue par un autre développeur qui souhaite apporter des modifications à l'original.

Cela semble un peu étrange jusqu'à présent, non ? Quiconque a déjà rencontré le développement open-source est déjà familiarisé avec cette approche. Cette stratégie offre l'avantage suivant : le développement peut se produire dans un référentiel fork sans accorder d'autorisations pour le développement conjoint dans la branche d'origine. Naturellement, le propriétaire du référentiel d'origine a le droit de rejeter les modifications proposées. Ou de les accepter et de les fusionner. Cela est pratique à la fois pour le propriétaire du référentiel d'origine et pour le développeur qui souhaite aider à créer le produit. Par exemple, vous pouvez suggérer des modifications au noyau Linux . Si Linus décide qu'ils ont du sens, les modifications seront ajoutées (!!!).

Un exemple de workflow de fork

Le workflow de fork est appliqué sur GitHub lorsqu'il existe une bibliothèque que vous souhaitez utiliser. Il a un bug qui vous empêche de l'utiliser pleinement. Supposons que vous approfondissiez suffisamment le problème et connaissiez la solution. À l'aide du workflow de fork, vous pouvez résoudre le problème sans avoir le droit de travailler dans le référentiel d'origine de la bibliothèque. Pour commencer, vous devez sélectionner un référentiel, par exemple, le Spring Framework . Recherchez et cliquez sur le bouton "Fork" dans le coin supérieur droit : cela prendra un certain temps. Ensuite, une copie du référentiel original apparaîtra dans votre compte personnel, ce qui indiquera qu'il s'agit d'un fork :Vous pouvez maintenant travailler avec ce référentiel comme d'habitude, en ajoutant des modifications à la branche principale, et lorsque tout est prêt, vous pouvez créer une demande d'extraction vers le référentiel d'origine. Pour ce faire, cliquez sur le bouton New pull request :

Quelle stratégie choisir

Git est un outil flexible et puissant qui vous permet de travailler en utilisant une grande variété de processus et de stratégies. Mais plus vous avez de choix, plus il est difficile de décider quelle stratégie choisir. Il est clair qu'il n'y a pas de réponse unique pour tout le monde. Tout dépend de la situation. Cela dit, il existe plusieurs lignes directrices qui peuvent aider à cela :

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 qui ont le moins de types de branches possible pour les développeurs.
3. Examinez les avantages et les inconvénients des différentes stratégies, puis choisissez celle dont vous avez besoin pour votre projet.

C'est tout ce que je voulais dire sur les stratégies de branchement dans Git. Merci pour votre attention :) Suivez-moi sur GitHub , où je poste souvent mes créations impliquant différentes technologies et outils que j'utilise dans mon travail.