Git
Analyse des types de workflows

Remarques

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 la release avant publication / déploiement.
• hotfix branches de hotfix sont destinées aux correctifs mineurs, qui ne peuvent pas attendre la prochaine version. hotfix branches de hotfix sortent de master et sont fusionnées en master et en develop .
• release branches de release sont utilisées pour libérer de nouveaux développements de develop à 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 en master et develop . 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 au develop lorsque vous avez terminé. Les feature 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