Trois approches
Vous pouvez utiliser l'une de ces techniques populaires ou vous pouvez les utiliser comme base pour créer la vôtre.
GitHub Flow . La stratégie est utilisée par l'équipe de service GitHub. Les principales exigences sont les suivantes:
- Il n'y a pas d'erreurs dans le code de la branche principale et il doit être prêt à être déployé à tout moment;
- pour commencer à développer une nouvelle fonctionnalité, vous devez créer une branche de fonctionnalité dans la branche principale et lui donner un nom qui est évident pour tout le monde. Lorsque le travail est prêt, il doit être fusionné dans la branche maître via une pull request;
- après la fusion des modifications, vous devez les déployer immédiatement sur le serveur.
Cette approche est généralement utilisée pour les produits avec une seule version qui n'est pas mise à jour très souvent. Par exemple, des sites Web. Du côté positif, cette approche permet aux développeurs de comprendre et d'organiser plus facilement leur travail. Le principal inconvénient est que si votre projet est suffisamment complexe et est mis à jour fréquemment, il vaut mieux utiliser une stratégie différente.
GitFlow . Il faut dire tout de suite que cette stratégie est discutable. Il y a beaucoup de critiques positives et négatives à son sujet.
La ligne du bas est la suivante. Il existe deux types de branches persistantes: la branche master, pour comprendre à quoi ressemble la dernière version actuelle, et la branche de développement, où le développement a lieu. Il existe trois types de branches temporaires.
- Fonctionnalité, pour ajouter de nouvelles fonctionnalités. Une fois le travail terminé, vous devez créer une pull request dans la branche de développement.
- Relâchez pour travailler sur de nouvelles versions. Il est important d'ajouter un numéro de version au titre, cela vous aidera à éviter toute confusion et à suivre les modifications.
- Hotfix, pour des corrections de bogues rapides.
Cette approche est considérée comme l'une des meilleures pour les projets où plusieurs versions sont constamment développées pour différentes plates-formes.
En 2010, le texte du programmeur néerlandais Vincent Driessen " Un modèle de branchement Git réussi " a été publié, dans lequel il a parlé pour la première fois de GitFlow. L'article est devenu très populaire, une traduction en russe est apparue et la méthode a été adoptée par de nombreuses équipes.
En 2020, le programmeur américain George Stoker a publié un article « Veuillez arrêter de recommander Git Flow", Où il a critiqué la méthode comme dépassée et inefficace dans les réalités modernes. Driessen, en réponse, a complété son texte de 2010 par une clause de non-responsabilité, dans laquelle il a admis que sa méthode n'était pas une panacée, mais seulement l'une des options pour organiser le travail.
Flux de travail de fourche. Ici, l'approche est la suivante: il existe un référentiel original pour fusionner toutes les modifications et une copie de celui-ci, dans lequel un autre développeur travaille. L'approche est très proche de l'idéologie open source, son objectif est d'utiliser tous les avantages de la communauté open source au sein du projet. Cependant, la plupart des workflows de branchement copient GitFlow. Les branches de fonctionnalités ici fusionneront avec les référentiels de développeurs locaux. Ainsi, le développement devient flexible même pour de très grandes équipes avec des sous-traitants.
Parmi ceux qui adoptent cette approche, il y a Linux . Vous pouvez proposer vos propres options pour modifier le code même pour le cœur du système. Et cette approche semble fonctionner efficacement.
Points généraux
Quel que soit le concept que vous choisissez, il est préférable de s'en tenir à certains points de base. Par exemple, voici les règles Microsoft :
- ne compliquez pas trop la stratégie de votre succursale;
- utiliser des branches de fonctionnalités pour toutes les mises à jour et corrections de bogues;
- fusionner les branches de fonctionnalités dans les branches principales en utilisant des pull requests;
- Gardez la qualité en amont et à jour.
Une stratégie basée sur ces idées conduira votre équipe à travailler avec des versions logiques et faciles à comprendre.
Voici quelques directives plus utiles.
Appelez ça simple et évident
Cela aidera tous les membres de l'équipe à comprendre correctement qui travaille sur quoi. Il est également acceptable d'inclure des informations supplémentaires dans le nom de la succursale, par exemple, le nom du créateur. C'est le cas lorsque vous n'avez pas besoin de trouver quelque chose d'original. Les noms de branche comme «utilisateurs», «correction de bogue», «fonctionnalité», «correctif» sont ce dont vous avez besoin. Pour les branches retardées, utilisez des indicateurs spéciaux séparés. Cela permettra à l'équipe de comprendre immédiatement ce qui est en jeu et de toujours garder ces tâches à l'esprit sur le long terme.
Fusionner des branches uniquement via une pull request
Le mécanisme de demande d'extraction s'est avéré logique et bien pensé. Étant donné que ce processus prend du temps, vous devez convenir au sein de l'équipe de ce que et dans quel délai est attendu de tous les participants à la pull request. Attribuez les responsabilités des examinateurs et partagez-les avec l'équipe via la base de connaissances interne.
Voici quelques conseils spécifiques:
- selon les recherches de Microsoft , le nombre optimal d'examinateurs est de deux;
- si votre équipe a déjà formé les principes de la révision du code, respectez-les et essayez de ne pas casser;
- Une pull request fonctionne beaucoup mieux lorsque davantage de membres de l'équipe sont régulièrement chargés de réviser le code;
- Laissez des descriptions de votre travail suffisamment détaillées pour que les réviseurs puissent saisir rapidement le contexte.
Configurer les politiques de la succursale
Cela vaut la peine de passer du temps sur les politiques de branchement pour plusieurs raisons:
- de cette façon, vous pouvez isoler le travail en cours du travail terminé dans la branche principale;
- imposer des restrictions raisonnables en déterminant qui et quels changements peuvent apporter à des succursales spécifiques;
- diffuser rapidement des méthodes de travail efficaces.
Il existe deux règles de base basées sur les stratégies à configurer:
- les réviseurs sont automatiquement ajoutés à une pull request au moment de sa création. Vous pouvez d'abord en définir une liste, puis les éditer au fur et à mesure;
- une génération réussie est requise pour terminer la demande d'extraction. Le code versé dans la branche principale doit être construit proprement.
Mais le principe le plus important lors de la création de votre stratégie de branche est le suivant: il faut y réfléchir pour que l'équipe n'ait pas de questions sur le sens de telle ou telle action. Alors chaque jour dans votre projet sera productif.
Blog ITGLOBAL.COM - Managed IT, clouds privés, IaaS, services de sécurité de l'information pour les entreprises: