Git rebase après une fusion (merge) git précédente

Question

J'ai la situation suivante:

• J'ai créé un clone (Y) à partir d'un dépôt principal (X), car il y avait beaucoup de personnes qui travaillaient sur Y nous n'avons pas fait de rebase mais seulement des merges. Lorsque nous voulons livrer (push) Y à X, nous aimerions faire un rebase afin d'avoir les choses propres et claires

Le problème est que lorsqu'on fait un rebase, on nous demande de refaire toutes les merges que nous avons déjà faites dans les étapes de merge précédentes. Y a-t-il une solution à cela, à part celle qui signifie effectivement refaire les merges?

Je m'attendais à ce que ce soit assez simple puisque nous avions déjà résolu les merges conflictuels.

Answer 1

git merge --squash est maintenant ma méthode préférée pour rebaser après avoir effectué un grand nombre de travaux et de fusions (voir cette réponse). Si la branche sur laquelle vous travaillez s'appelle my-branch et que vous souhaitez rebaser depuis main alors faites simplement ce qui suit :

git checkout my-branch
git branch -m my-branch-old       # renommer de my-branch à my-branch-old
git checkout main
git checkout -b my-branch         # créer une nouvelle branche my-branch
git merge --squash my-branch-old  # écraser et fusionner les changements de l'ancienne branche
git commit

Answer 2

Rebaser pour obtenir un historique "propre" est surestimé. La meilleure façon si vous voulez préserver l'historique est simplement de faire la fusion au lieu d'un rebasage. De cette façon, si vous avez besoin de revenir à une révision, elle est exactement la même que celle que vous avez testée pendant le développement. Cela résout également votre problème concernant les conflits de fusion précédemment résolus.

Si vous ne vous souciez pas de préserver l'historique, vous pouvez créer une nouvelle branche à partir de master, la vérifier, puis faire un git read-tree -u -m dev pour mettre à jour votre arborescence de travail afin de correspondre à la branche dev. Ensuite, vous pouvez commettre tout en un grand commit et le fusionner dans master normalement.

Answer 3

Deux remarques :

• vous pouvez rebaser votre propre travail (non encore poussé) autant de fois que vous le souhaitez sur les nouveaux commits récupérés.
• Vous pourriez éviter les conflits de fusion (lors du rebase) si vous aviez activé git rerere, ce qui est fait pour ce genre de situation.
  Voir plus sur git rerere.

Answer 4

Vous pouvez prendre toutes les modifications de votre branche et les mettre dans un nouveau commit dans master avec ce qui suit :

git diff master > my_branch.patch
git checkout master
patch -p1 < my_branch.patch

Ensuite, mettez en staging vos fichiers et faites un commit.

Answer 5

En ce qui concerne la résolution des conflits de fusion, vous pouvez utiliser git rerere pour maintenir une base de données de la façon dont les conflits de fusion ont déjà été résolus, de sorte qu'une réorganisation qui entraîne les mêmes conflits aura les parties laborieuses effectuées automatiquement pour vous.

https://hackernoon.com/fix-conflicts-only-once-with-git-rerere-7d116b2cec67

git config --global rerere.enabled true

La seule chose à surveiller est que si vous avez résolu quelque chose incorrectement, cela sera automatiquement bâclé pour vous la prochaine fois également, et vous pourriez ne pas vraiment vous en rendre compte.

Une documentation plus formelle ici : https://git-scm.com/docs/git-rerere