En git, l'édition d'un pré-pull engager après la traction provoque une divergence d'origine

Question

historique Dans le scénario suivant:

1. Marque engage A, B, C
2. Pull, s'engage D, E
3. Faire plus engage F, G, H, ...
4. Rendez-vous compte que vous devez modifier B
5. Tweak B à l'aide git rebase -i et git commit --amend

Maintenant git status dit:

Your branch and 'origin/master' have diverged. 

Comment dois-je résoudre ce problème?

Remarque: je n'ai pas poussé; cela n'a rien à voir avec pousser.

Remarque: Le simple fait de tirer à nouveau ne résout pas le problème; il recompose juste les commits D, E en plus de ce que j'ai déjà (bien que le D, E soit déjà là dans l'histoire), ce qui a aussi l'effet secondaire de produire des conflits superflus.

Pour élaborer, une réponse ci-dessous suggère que l'histoire est maintenant:

- A - B' - C' - F' - G' - H' (master) 
\ 
D - E (origin/master) 

Ce n'est pas tout à fait raison - il est en fait:

- A - B' - C' - D(?) - E(?) - F' - G' - H' (master) 
\ 
D - E (origin/master) 

Par conséquent, mon problème. Je voudrais que ce soit:

- A - B' - C' - F' - G' - H' (master) 
\  /
D - E (origin/master) 

Answer 1

Note: Je n'accepterai pas ma propre réponse pendant un moment parce que je suis vraiment curieux à propos d'autres (meilleures) approches.

La façon dont je suis sorti de c'était à peine élégante:

# stash F, G, H - can't simply reorder them before D, E since they depend a lot on D, E 
for i in {1..3}; do git reset HEAD^; git stash; done 
# wipe out the weird non-merge D and E commits 
git reset --hard HEAD~2 
# pull to merge D, E again 
git pull 
# restore F, G, H 
for i in {1..3}; do git stash pop; git commit -a; done 

Answer 2

Je devine que vous n'avez pas utilisé l'option -p à git rebasage, ce qui signifie que la traction que vous avez fait, la fusion engage D et E, a été essuyée. Si c'est tout ce qui est arrivé, c'est simple: il suffit de tirer à nouveau. Si c'est ce qui s'est passé, votre histoire ressemblera à ceci:

- A - B' - C' - F' - G' - H' (master) 
\ 
D - E (origin/master) 

Il y a votre divergence!

Si vous avez préservez la fusion, alors ceci est tout à fait peut-être juste parce que quelque chose de nouveau a été poussé à l'origine dans l'intervalle:

- A - B' - C' - X' - F' - G' - H' (master) 
\   /
D - E -------- - Z (origin/master) 

et donc la solution, encore une fois, serait de tirer.

Si, toutefois, vous avez poussé quelque chose contenant le commit d'origine B, vous ne devriez pas avoir rebasé. Cela causera toujours des divergences, et ce n'est pas un amusement. Votre histoire ressemblerait à ceci:

B' - C' - F' - G' - H' (master) 
/
- A - B - C - X - F - G - H (origin/master) 
\   /
D - E ------ 

Il est un fait fondamental de la conception de git que le SHA1 d'un engagement dépend du SHA1 de son parent, et donc sur l'ensemble de la chaîne d'ascendance. C'est pourquoi après les rebasages, j'ai mis un "prime" sur tout. Même si vous n'avez pas modifié le contenu de C, la validation est modifiée.(L'autre possibilité, que vous ayez préservé la fusion, et poussé, devrait être inferrable comme une combinaison des deux dernières images.)