Git-flow et master avec plusieurs branches de release parallèles
Nous essayons d'adopter le modèle de branchement Git réussi implémenté par git-flow. Nous travaillons actuellement 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" au maître et y sont étiquetées. Pourquoi ne pas taguer les communiqués dans leurs branches de publication? Pourquoi le maître ? Ou pourquoi une développer une branche et ne pas utiliser maître pour cela?
Dans le modèle git-flow, votre version "la plus récente" correspond en fait à la master, tandis que votre "version de prévisualisation" correspond à une branche git-flow release. Il est créé à partir de develop et finalement fusionné dans master lorsque la version réelle se produit. Cela deviendra alors votre "dernière version" et vous ne corrigerez généralement que les bogues de cette version, en utilisant git-flow hotfixbranches. De cette manière, votre master représente toujours l'état le plus stable de votre dernière version publiée.
Si vous voulez corriger des bogues d'anciennes versions ou faire tout autre développement là-bas, vous allez créer une branche support à partir du commit approprié dans master (vous aurez toutes les versions jamais créées ici). support les branches sont encore expérimentales ( selon la documentation ) et ne sont pas bien documentées. 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 font que commencer et ne sont pas destinées à être fusionnées avec master ni develop. Cela convient généralement bien, car les correctifs apportés aux versions "anciennes" ou les fonctionnalités demandées par les clients à implémenter dans les versions "anciennes" ne peuvent pas ou ne doivent pas revenir dans master. Si vous pensez toujours que vous souhaitez porter un correctif sur votre ligne de développement principale (représentée par master et develop), il vous suffit de lancer un hotfix, de sélectionner vos modifications et de terminez le hotfix.
On dirait surtout un modèle mental avec un peu trop d'emphase sur les branches. Je suis d’accord, vous pouvez simplement marquer les commits que vous relâchez au lieu de les fusionner dans master.
La photo est jolie, cependant. La fusion de tout dans le maître donne 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 de bugs dans les versions précédentes, cependant. Il gâche la commande ordonnée.
- Supposons que nous ayons publié la version 1.0.1 et ultérieure, des fonctionnalités ajoutées et la version 1.1.0.
- Nous découvrons un bogue dans la version 1.0.1 et souhaitons le corriger dans les deux versions.
- Nous devons ajouter 1.0.2 après 1.1.0 en master et ensuite atfer (ou avant) également 1.1.1.
Pour répondre à votre question: je pense qu’il s’agit d’un ensemble de règles qui, dans certains cas, constituent un modèle mental simple. 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.
Personnellement, je pense que le git-flow mentionné est trop compliqué.
Si vous utilisez GitHub, essayez le GitHub flow (comme décrit par Scott Chacon).
Il est particulièrement utile pour la collaboration sur plusieurs fonctionnalités, la révision de code et vous pouvez le combiner avec votre solution d’intégration continue à l’aide de la commande Commit Status API .
[~ # ~] mise à jour [~ # ~] : Il y a une nouvelle site officiel de The GitHub Flow ™
UPDATE 2 : Il existe un nouveau guide GitHub officiel (et simplifié) pour The GitHub Flow ™: https: //guides.github. com/introduction/flux /
Totalement d'accord avec @Mot.
C'est bien d'entendre les mêmes questions.
Notre équipe a également été recherchée pour plus de modèles de branchement universels que Successfull un. C'est à dire. Comme @Mot mentionné ci-dessus - l'idée principale est d'éviter d'introduire des référentiels supplémentaires pour prendre en charge les branches release- * dans un dépôt séparé * .git, comme cela est fait par exemple par kernel.org pour les versions stables. Mais kernel.org le fait pour minimiser les tailles téléchargées, je suppose.
Pour moi, il semble plus propre d’avoir le maître comme ligne principale pour développer .
Il y a aussi des conflits dans release- * fusing model à master et en le balisant par la suite avec l'idée de
utilisez un script Git hook pour construire et déployer automatiquement notre logiciel sur nos serveurs de production chaque fois qu'il y avait un commit sur master
cause finition (fusion et marquage) 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 avec la prise en charge du contrôle de version automatisé:
$git describe --tags --long >.ver
alors une version erronée peut être construite pour:
$ git merge --no-ff release-1.2
Je sais que la gestion des versions dans Successfull introduit quelques processus bump-version mais ce n'est pas automatique.
Donc, pour résumer - les différences clés que nous introduisons dans le modèle de branche pour les versions- * la fusion et le balisage sont: - la version de balisage sur la création de sa branche - conservez la branche de la version pour permettre leur maintenance à l'avenir
Dans mon cas, j'ai deux versions du même logiciel dont les bases sont les mêmes mais chaque version a ses propres caractéristiques.
Je crée donc deux worktree, ce qui signifie créer deux branches pertinentes à long terme à côté du maître.
$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master
Ensuite j'ai:
$git branch
master # base stuff here
version-silver # some normal features
version-gold # some better features
Il y a un référentiel, 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 le maître. 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 modifications spécifiques de chaque version iront également dans le dossier correspondant, et les travaux de chaque projet seront isolés et IDE ne serait pas dérouté.
J'espère que ça t'as aidé.