Git-flow et master avec plusieurs branches de publication parallèles

Question

Nous essayons d'adopter la modèle de branchement Git réussi mis en œuvre par git-flow. Maintenant, nous travaillons sur au moins deux branches de publication, une pour la dernière version stable et une pour la prochaine version ("preview"). Ce que je ne comprends pas, c'est pourquoi toutes les versions semblent "linéarisées" vers la branche maître et étiqueté là. Pourquoi ne pas étiqueter les versions dans leurs branches de publication ? Pourquoi les maître du tout ? Ou pourquoi un développer et ne pas utiliser maître pour ça ?

Answer 1

Dans le modèle git-flow, votre version "last released" correspond en fait à la version master tandis que votre "version préliminaire" correspond à un flux git. release branche. Il est bifurqué de develop et finalement fusionné dans master quand la sortie réelle aura lieu. Celle-ci deviendra alors votre "dernière version" et vous ne corrigerez généralement que les bogues de cette version, en utilisant le git-flow. hotfix branches. De cette façon, votre master représente toujours l'état le plus stable de votre dernière version publiée.

Si vous souhaitez corriger des bogues pour des versions plus anciennes ou effectuer d'autres développements, vous devrez créer un fichier d'échange de données. support à partir du commit approprié dans master (vous aurez tous versions jamais créées à cet endroit). support sont encore expérimentales ( selon les docs ) et ne sont pas bien documentés. Mais comme vous pouvez le voir dans l'aide en ligne de commande :

usage: git flow support [list] [-v]
       git flow support start [-F] <version> <base>

ces branches ne sont qu'amorcées et ne sont pas destinées à être fusionnées à nouveau master ni develop . C'est généralement une bonne chose, car les correctifs apportés aux "anciennes" versions ou les fonctionnalités dont l'implémentation a été demandée par les clients dans les "anciennes" versions ne peuvent pas ou ne doivent pas être réintégrés dans le système de gestion de l'information. master . Si vous pensez toujours que vous voulez porter un correctif sur votre ligne de développement principale (représentée par master y develop ), il suffit de lancer un hotfix vous pouvez choisir vos changements et terminer l'opération. hotfix .

Answer 2

On dirait surtout un modèle mental avec un peu trop d'emphase sur les branches. Je suis d'accord, vous pourriez simplement marquer les commits que vous publiez au lieu de les fusionner dans master.

La photo est jolie, cependant. En fusionnant tout dans le master, on obtient une indication claire des versions dans l'ordre temporel au lieu d'avoir des étiquettes de version éparpillées sur le graphique.

Je pense que ce modèle ne fonctionne pas pour la correction des bogues dans les anciennes versions, cependant. Cela perturbe l'ordre des choses.

1. Disons que nous avons publié la version 1.0.1, puis ajouté des fonctionnalités et publié la version 1.1.0.
2. Nous avons découvert un bug dans la version 1.0.1 et nous voulons le corriger dans les deux versions.
3. Nous devons ajouter la 1.0.2 après la 1.1.0 dans le master et ensuite directement après (ou avant) la 1.1.1.

Pour répondre à votre question : Je pense que c'est un ensemble de règles qui constitue un modèle mental simple dans certains cas. Toutes les règles n'ont pas de sens d'un point de vue purement technique, mais cela ne les rend pas mauvaises. Les modèles mentaux sont bons pour les humains.

Answer 3

Dans mon cas, j'ai deux versions du même logiciel dont les bases sont les mêmes mais chaque version a des fonctionnalités différentes.

Je crée donc deux worktree c'est-à-dire créer deux branches pertinentes et durables à côté de la branche principale.

$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master

Alors je l'ai fait :

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

Il y a un seul dépôt, mais j'ai 3 dossiers séparés les uns à côté des autres pour chaque branche ci-dessus. Et faire les changements communs dans master. puis le fusionner avec les deux autres versions.

cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project

Les changements spécifiques de chaque version seront également placés dans le dossier correspondant, et les travaux sur chaque projet sont isolés et l'IDE ne sera pas confondu.

J'espère que cela vous aidera.

Answer 4

Je pense personnellement que le git-flow mentionné est trop compliqué.

Si vous utilisez GitHub, essayez l'option GitHub flow (comme décrit par Scott Chacon).

Il est particulièrement utile pour la collaboration sur de multiples fonctionnalités, l'examen du code et vous pouvez le combiner avec votre solution d'intégration continue à l'aide de l'outil de gestion de l'intégration. Commit Status API .

UPDATE : Il y a un nouveau site officiel de The GitHub Flow™

MISE À JOUR 2 : Il existe un nouveau guide officiel (et simplifié) de GitHub pour The GitHub Flow™ : https://guides.github.com/introduction/flow/

Answer 5

Totalement d'accord avec @Mot.

C'est agréable d'entendre les mêmes questions.

Notre équipe a également été chassée pour un modèle de branchement plus universel que Succès de un. Comme @Mot l'a mentionné plus haut, l'idée principale est d'éviter d'introduire des dépôts supplémentaires pour supporter les branches release-* dans des dépôts *.git séparés, comme le fait par exemple kernel.org pour les versions stables. Mais kernel.org le fait pour minimiser la taille des téléchargements, je suppose.

Pour moi, il me semble que c'est plus propre d'avoir maître comme ligne principale pour développer .

Il y a également quelques conflits dans modèle de fusion release-* a maître et l'étiqueter ensuite avec l'idée de

utiliser un hook Git script pour construire et déployer automatiquement notre logiciel sur nos serveurs de production chaque fois qu'il y a un commit sur master.

cause finition (fusion et étiquetage) n'est pas une transaction atomique :

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

et si git hook démarre la construction avec le support du versioning automatique :

$git describe --tags --long >.ver

alors il est possible de construire une version erronée :

$ git merge --no-ff release-1.2

Je sais que le versioning dans Succès de on introduit des le processus de version bump mais ce n'est pas automatique.

Pour résumer, les principales différences que nous introduisons dans le modèle de branche pour la fusion et le marquage des versions sont les suivantes : - étiquetage de la version lors de la création de sa branche - conserver la branche de la version pour permettre de la maintenir à l'avenir