Git rebase 压缩提交可将本地恢复到之前的多个提交

Question

我对我的分支做了一些提交，然后使用 CR 将其合并到 master 中。我希望对该分支的所有提交都被压缩，所以我尝试了

git rebase -i HEAD~3

并将最近的两个提交压缩为第三个最近的提交。

然后修改了我的本地文件，在当前版本的 master 和 master 合并 CR 之前的几次提交之间产生了某种混合。现在有几个代码块包含在

中

<<<<<<< HEAD
{code from before CR merge}
=======
{code from current version of master}
>>>>>>> Branch hash from 8 commits before the CR merge

为什么压缩最近的两次提交会复活 8 次提交之前的更改？

我也尝试了

git reset HEAD~2 --soft

，但是

git log

没有显示任何更改或表明这两个提交已被压缩到另一个提交中。

git log --graph --pretty=%h HEAD~3..HEAD

（运行后

git reset HEAD~2 --soft

）产生

*   9387a5c
|\  
| * f7624c3
| * f68a001
| * d7729a5
|/  
*   8a1d144
|\  
| * dea1b19
| *   70d5197
| |\  
| |/  
|/|   
* | a5fe680
* | 35b9417
* | 1f3f921
* | ea1d7e5
* | 11a7fb4
* | 021e8c5
* | 5b9db7a
 /  
* b2e4905

9387a5c

来自于合并CR。

git rebase

不允许我压制该提交，只能从

f7624c3

开始。我尝试将

f7624c3

和

f68a001

压缩为

d7729a5

，因为它们都提交到同一功能的同一分支。

Answer 1

我看到

HEAD

指向合并提交 (

9387a5c

)，这意味着：执行

git rebase -i HEAD~3

会 not 将所述合并提交包含为可以压缩的内容。默认情况下，交互式变基只是从

todo

列表中删除合并提交，除非您启用

--rebase-merges

（自 Git 2.22，20219 年第 2 季度开始默认）（或旧版 Git 中的 --preserve-merges

）。这就是为什么你只能从 

f7624c3

 开始选择/挤压，而不是从合并提交中选择/挤压。

当您在这种情况下执行

git rebase -i HEAD~3

 时，Git 会看到来自主历史记录中较旧点的功能分支的提交。然后，它尝试在最新的主更改上再次应用这些补丁，从而引发看起来像“古老”代码重新出现的冲突。

而且，正如

amphetamachine 在 他们的评论中提到的那样，当合并提交包含不纯粹在其父级中的更改时，git rebase

 会变得更加复杂，使其不仅仅是简单的快进或无操作合并。因此，当您在变基期间“重放”合并时，Git 可能会尝试重新应用冲突解决方案。这也是当您看到来自旧提交的“复活”更改时。