Garder un historique Git propre lors de l'utilisation de Gitflow - Unmerged s'engage sur le développement

9

En utilisant gitflow, lors de la création d'une release-1.0.0branche et de sa fusion avec les deux masteret develop, les deux branches auront un commit manquant:

  • mastern'aura pas le commit où release-1.0.0était fusionnerdevelop
  • developn'aura pas le commit où release-1.0.0était fusionnermaster

Au lieu de cela, après avoir hotfix-1.0.1été créé et fusionné master, lors de sa fusion develop, les validations à fusionner incluront la validation précédente où a release-1.0.0été fusionné master; il ressemblera à ceci:

User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'.

* merge release-1.0.0 to master
* merge release-1.1.0 to master
* Fix shopping cart critical bug

Si cela vous semble confus, vous pouvez facilement remarquer ce everytie que vous voyez developest généralement quelques commits derrière master(même si développer, théoriquement, devrait seulement être en avance car il est la branche principale. Ces commits sont des fusions de release-x.x.xla master).

Comment cela devrait-il être géré pour maintenir une histoire propre?

git gitflow Christopher Francisco
la source
Veuillez définir "l'historique propre".
Jace Browning
3
Vous voulez une histoire propre? N'utilisez pas gitflow. Il pollue par définition votre histoire. Au lieu de cela, pensez à ce dont vous avez vraiment besoin et créez un flux de travail autour de cela, afin qu'il corresponde réellement à la façon dont vous voulez travailler.
FP
1
La fusion à master sera une "copie", pas besoin de la fusionner pour la développer. Effectuez des correctifs à chaud à partir de la branche de la version précédente, pas maître, et fusionnez-les à partir de là, et vous n'aurez pas le problème. Maître n'ajoute pas grand-chose au modèle, vous pouvez donc le supprimer complètement, IMO.
axl
@axl Je comprends ce que vous voulez dire, mais j'essaie de suivre gitflow aussi près que possible de sa documentation. Je préfère ne pas faire de "hackz" parce que gitflow est déjà adopté par de nombreux développeurs, ils devraient déjà avoir une solution pour cette chose simple
Christopher Francisco
Il y a plusieurs discussions sur la façon de résoudre divers problèmes avec GitFlow sur GitHub et d'autres endroits. Parfois, il n'y a tout simplement pas de solution miracle.
axl

Réponses:

4

Je pense qu'une bonne approche est d'éviter d'avoir deux branches "principales", master et develop sont en quelque sorte redondantes. C'est expliqué en détail ici , marqué cactus-flowpar l'auteur.

Certains points ressortent par opposition à git-flow:

  • Une seule branche principale
  • Fusion rapide uniquement

Pour moi, le dernier est important, car après avoir utilisé git-flow pendant une longue période, je ne vois pas encore ce qui est utile à propos des --no-fffusions.

J'essaie de suivre gitflow aussi près que possible de sa documentation. Je préfère ne pas faire de "hackz" parce que gitflow est déjà adopté par beaucoup de développeurs, ils devraient déjà avoir une solution pour cette chose simple

À mon humble avis, c'est votre grosse erreur. Il n'y a aucune raison pour que vous vous en teniez autant que possible à Git-Flow. Il peut être utilisé dans des milliers de projets mais cela n'affecte pas le vôtre, ne le rend pas bon.

Git-flow est un bon point de départ, mais vous devriez penser à l'adapter à vos outils et à votre flux de travail plutôt que l'inverse.

Sergio Basurco
la source