Git 为什么rebase不允许修改合并提交？

如果当前提交是合并提交，为什么

git-rebase-i HEAD~

没有将其包含在我可以修改的提交中

rebase

的文档在哪里说不能修改合并提交

下面是一个简单的设置，它显示了我的意思：

git init test_git
cd test_git
touch a
git add a
git commit -m "added a"
git branch feature
git checkout feature
echo "version 1" >a
git commit -a -m "version 1"
git checkout master
echo "version 2" >a
git commit -a -m "version 2"
git merge feature
echo "version 3" >a
git commit -a -m "resolved merge"
git rebase -i HEAD~~

此时，我在文本编辑器中看到以下消息：

pick 6746909 version 2
pick 830dbd0 version 1

# Rebase 3848032..d7c0f38 onto 3848032

---

当前（合并）提交是d7c0f38，注释中甚至提到了它。但我实际上没有选择/编辑/挤压等提交操作。

因为默认情况下，

git-rebase

不保留合并。这可以通过

--preserve merges

关闭，但文档状态

这在内部使用了--interactive机制，但如果您不知道自己在做什么，那么将其与--interactive选项显式结合通常不是一个好主意（请参见下面的bug）

is

git-rebase

的原因实际上是在另一次提交的基础上重放您的提交，因此合并被消除。为了说明原因，我复制了你的回购协议

$ git log --oneline --graph --decorate
*   5eb2e82 (HEAD -> master) resolved merge
|\  
| * 42cfeab (feature) version 1
* | d6a71b8 version 2
|/  
* 267627b added a

当我运行

git rebase-I HEAD~~

时，我看到：

pick d6a71b8 version 2
pick 42cfeab version 1

# Rebase 267627b..5eb2e82 onto 267627b (2 commands)

请注意，最后一位是“到267627b”，即“添加了一个”提交。这两个提交，“版本1”和“版本2”将在“添加a”的顶部进行修补。结果将是线性的，不需要合并

由于分支机构的原因，甚至还有一个必须解决的冲突。两个提交都将同一行从“added a”改为“added a”，因此无论它们执行的顺序如何，它们都会发生冲突

冲突解决了，结果如下

* d6a71b8 (HEAD -> master) version 2
* 267627b added a

“版本1”的变化到哪里去了？解决冲突意味着“版本1”不再有任何更改，因此重定基础删除了空提交。它这样做是为了避免重新引入可能已经合并到中的提交。您可以使用

——keep empty

关闭此行为，尽管没有什么理由这样做

---

如果您确实想保留合并，我建议您首先在master上重新设置功能分支的位置，然后合并并强制合并。假设你有这个

A - B - C - G - H [master]
         \
          D - E - F [feature]

首先，将特征重设为主特征

git checkout feature
git rebase master

A - B - C - G - H [master]
                 \
                  D1 - E1 - F1 [feature]

这导致了一个线性历史，功能现在位于主控上，任何冲突都必须解决，并且可以使用主控的所有更新测试功能

一旦功能测试完成，就可以将其与主功能合并。由于主控没有新的更改，通常合并会快速进行，从而导致这种情况

A - B - C - G - H - D1 - E1 - F1 [feature]
                                 [master]

现在很难看到作为功能的一部分所做的更改，这是将来调试的重要环境。相反，我们希望通过

--无ff

来保证合并提交

git checkout master
git merge --no-ff feature

结果是这样的：

A - B - C - G - H ------------ I [master]
                 \            /
                  D1 - E1 - F1 [feature]

历史是线性的，而且很清楚哪些提交是作为一个分支一起完成的，合并提交可以用来解释这个分支

---

这是我合并功能分支的正常过程。

每次我觉得我理解了基本git，我就会发现还有一件非常重要的事情我不知道。@max界面让人觉得git做了103487件事，但git实际上只做了4件事。如果您了解了图形（提交是如何连接的）、对象ID、标签（分支和标记）以及暂存区域是如何工作的，那么其他一切都会突然变得有意义。