Git
Analyse des types de workflows
Recherche…
Remarques
Utiliser un logiciel de contrôle de version tel que Git peut être un peu effrayant au début, mais sa conception intuitive, spécialisée dans la création de branches, permet de créer différents types de flux de travail. Choisissez celui qui convient à votre propre équipe de développement.
Workflow Gitflow
Initialement proposé par Vincent Driessen , Gitflow est un workflow de développement utilisant git et plusieurs branches prédéfinies. Cela peut être considéré comme un cas particulier du workflow Feature Branch .
L'idée de celui-ci est d'avoir des branches séparées réservées à des parties spécifiques en développement:
-
master
branche principale est toujours le code de production le plus récent. Le code expérimental n'appartient pas ici. -
develop
branche contient tous les derniers développements . Ces changements de développement peuvent être à peu près n'importe quoi, mais des fonctionnalités plus importantes sont réservées à leurs propres branches. Le code ici est toujours travaillé et fusionné dans larelease
avant publication / déploiement. -
hotfix
branches dehotfix
sont destinées aux correctifs mineurs, qui ne peuvent pas attendre la prochaine version.hotfix
branches dehotfix
sortent demaster
et sont fusionnées enmaster
et endevelop
. -
release
branches derelease
sont utilisées pour libérer de nouveaux développements dedevelop
àmaster
. Tous les changements de dernière minute, tels que les numéros de version superflus, sont effectués dans la branche de publication, puis sont fusionnés enmaster
etdevelop
. Lors du déploiement d'une nouvelle version,master
doit être associé au numéro de version actuel (par exemple, à l'aide du contrôle de version sémantique ) pour référence ultérieure et restauration rapide. -
feature
sont réservées aux fonctionnalités plus importantes. Celles-ci sont spécifiquement développées dans des branches désignées et intégrées audevelop
lorsque vous avez terminé. Lesfeature
dédiées aident à séparer le développement et à pouvoir déployer des fonctionnalités effectuées indépendamment les unes des autres.
Une représentation visuelle de ce modèle:
La représentation originale de ce modèle:
Flux de travail
Ce type de flux de travail est fondamentalement différent des autres mentionnés sur ce sujet. Au lieu d'avoir un référentiel centralisé auquel tous les développeurs ont accès, chaque développeur dispose de son propre référentiel, issu du dépôt principal. L'avantage de ceci est que les développeurs peuvent publier dans leur propre dépôt plutôt qu'un référentiel partagé et qu'un responsable peut intégrer les modifications des repos reposé dans l'original, le cas échéant.
Une représentation visuelle de ce flux de travail est la suivante:
Workflow centralisé
Avec ce modèle fondamental de workflow, un master
branche contient tout développement actif. Les contributeurs devront être particulièrement sûrs de tirer les dernières modifications avant de poursuivre leur développement, car cette branche évoluera rapidement. Tout le monde a accès à ce dépôt et peut engager des modifications directement dans la branche principale.
Représentation visuelle de ce modèle:
C'est le paradigme classique du contrôle de version, sur lequel des systèmes plus anciens tels que Subversion et CVS ont été construits. Les logiciels fonctionnant de cette manière sont appelés systèmes de contrôle de version centralisés ou CVCS. Bien que Git soit capable de fonctionner de cette façon, il existe des inconvénients notables, tels que la nécessité de précéder chaque traction par une fusion. Il est très possible pour une équipe de travailler de cette façon, mais la résolution constante des conflits de fusion peut finir par prendre beaucoup de temps précieux.
C'est pourquoi Linus Torvalds a créé Git non pas en tant que CVCS, mais plutôt en tant que système de contrôle de version distribué ( DVCS ) ou distribution , similaire à Mercurial. L'avantage de cette nouvelle façon de faire est la flexibilité démontrée dans les autres exemples de cette page.
Workflow de la fonction Feature
L'idée de base derrière la Direction générale Feature Workflow est que tout le développement de fonctionnalités devrait avoir lieu dans une branche dédiée au lieu du master
branche. Cette encapsulation facilite le travail de plusieurs développeurs sur une fonctionnalité particulière sans perturber la base de code principale. Cela signifie également que la branche master
ne contiendra jamais de code cassé, ce qui représente un avantage considérable pour les environnements d'intégration continue.
Le développement de fonctionnalités d'encapsulation permet également de tirer parti des requêtes d'extraction, qui permettent d'initier des discussions autour d'une branche. Ils permettent aux autres développeurs d’accepter une fonctionnalité avant qu’elle ne soit intégrée au projet officiel. Ou, si vous êtes coincé au milieu d'une fonctionnalité, vous pouvez ouvrir une demande de tirage en demandant des suggestions à vos collègues. Le fait est que les demandes de tirage facilitent énormément les commentaires de votre équipe sur le travail de chacun.
basé sur des didacticiels Atlassian .
GitHub Flow
Populaire dans de nombreux projets open source, mais pas seulement.
La branche principale d'un emplacement spécifique (Github, Gitlab, Bitbucket, serveur local) contient la dernière version livrable. Pour chaque nouvelle fonctionnalité / correction de bogue / changement architectural, chaque développeur crée une branche.
Les modifications se produisent sur cette branche et peuvent être discutées dans une demande d'extraction, une révision de code, etc. Une fois acceptées, elles sont fusionnées dans la branche principale.
Flux complet par Scott Chacon:
- Tout ce qui se trouve dans la branche principale est déployable
- Pour travailler sur quelque chose de nouveau, créez une branche nommément nommée à partir de master (ex: new-oauth2-scopes)
- S'engager localement dans cette branche et pousser régulièrement votre travail sur la même branche nommée sur le serveur
- Lorsque vous avez besoin de commentaires ou d'aide, ou que vous pensez que la succursale est prête à fusionner, ouvrez une demande d'extraction.
- Une fois que quelqu'un a passé en revue et signé la fonctionnalité, vous pouvez la fusionner en master
- Une fois fusionné et poussé à «maîtriser», vous pouvez et devez déployer immédiatement
Présenté à l'origine sur le site Web personnel de Scott Chacon .
Image reproduite avec l'aimable autorisation de la référence GitHub Flow