GitFlow, suppression et fusion des problèmes

Question

J'utilise GitFlow dans mon dépôt git, donc j'ai une master , develop et (temporaire) release branche.

Flux de travail

1. Je crée une nouvelle branche à partir de develop (par exemple fix/fix-the-bug )
2. J'écrase mon correctif dans des commits significatifs.
3. Je fusionne mon fix/fix-the-bug dans la branche develop
4. Une fois que j'ai fusionné un nombre suffisant de branches, je crée une branche (temporaire) release/x.y.z de la branche develop
5. J'ai changé de version de mes scripts dans le système de gestion de l'information. release/x.y.z branche et marque ce commit
6. Quand je veux fusionner release/x.y.z en master j'ai des conflits de fusion. Il semble que master ne comprend pas que les commits sont déjà présents dans l'application master
7. release/x.y.z est fusionnée avec la branche develop
8. Je supprime release/x.y.z

Quelques points à noter, je ne suis pas sûr qu'ils soient tous corrects :

• J'écrase mes commits en un seul lors de la fusion avec master.
• Il devrait y avoir un tag git sur master indiquant le numéro de version, mais je ne suis pas sûr que cela fonctionne correctement si j'écrase les commits.

Question

Je me demande maintenant :

• comment je peux corriger mon repo, puisque je ne pense pas que je devrais avoir ces conflits.
• Tout autre conseil sur le flux de travail (par exemple, dans quelle partie je pourrais le mieux réaliser le squash) serait le bienvenu.

Answer 1

J'écrase mes commits en un seul lors de la fusion avec master.

On dirait que vous utilisez git merge --squash lorsque vous fusionnez avec master . Ce n'est pas une pratique standard de gitflow ; vous feriez simplement une fusion normale.

La seule différence entre une fusion ordinaire et une fusion accélérée est qu'une fusion accélérée n'enregistre pas la relation entre le nouveau commit sur la branche dans laquelle vous fusionnez (c.-à-d. master dans ce cas) et les commits originaux sur la branche source ; c'est pourquoi les fusions ultérieures ne comprennent pas que le contenu sur master correspond déjà à un état antérieur de develop .

L'"inconvénient" de l'utilisation d'une fusion régulière est que la sortie par défaut de git, lors de la journalisation, est la suivante master par exemple, inclurait tous les commits individuels au lieu d'une simple liste des commits de la version sur master mais vous pouvez y remédier en utilisant l'option --first-parent option.

Pour illustrer cela, vous commencez avec un dépôt vierge.

o <--(master)

Sans créer de commits, vous lancez le develop et ensuite une fix branche sur laquelle vous travaillez

o <--(master)(develop)
 \
  A <--(fix)

Vous fusionnez avec dev

o <--(master)
|
|- M <--(develop)
\ /
 A <--(fix)

Vous pourriez faire plus de réparations

o <--(master)
|
|- M - M2 <--(develop)
| / \ /
| |  B <--(fix2)
\ |
 A <--(fix)

Maintenant si vous écrasez la fusion vers master, vous obtiendrez quelque chose comme

o -------- AB <--(master)
|
|- M - M2 <--(develop)
| / \ /
| |  B <--(fix2)
\ |
 A <--(fix)

y AB contient tous les changements que A y B introduit, mais en ce qui concerne git, c'est une coïncidence ; et une fois que develop contient des changements additionnels, même le fait que les changements sont "les mêmes" sera perdu, et des conflits (comme vous l'avez expérimenté) en résulteront.

Donc, au lieu de cela, vous faites une fusion normale - il suffit de ne pas tenir compte de l'élément --squash en supposant que vous utilisiez les fusions d'écrasement en premier lieu :

o ------- AB <--(master)
|        /
|- M - M2 <--(develop)
| / \ /
| |  B <--(fix2)
\ |
 A <--(fix)

C'est ainsi que git veut que les fusions fonctionnent ; maintenant, les futures tentatives de fusion "sauront" que M2 (et tout ce que cela implique) est déjà inclus dans master et ne change qu'après M2 seront inclus comme "leurs changs" dans le calcul de la fusion.

C'est également la façon dont gitflow souhaite que les choses soient faites.