git - 为什么 rebase 不允许修改 merge 提交？

Question

如果当前提交是 merge 提交，为什么 git rebase -i HEAD~~ 没有将它包含在我可以修改的提交中？

rebase 的文档在哪里说不能修改 merge 提交？

这是一个简单的设置，可以说明我的意思:

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

当前( merge )提交是 d7c0f38，甚至在评论中也提到了它。但它不在我实际选择/编辑/挤压/等的提交中。

Answer 1

因为 git rebase 默认情况下不保留 merge 。这可以用 --preserve-merges 关闭，但是文档状态...

This uses the --interactive machinery internally, but combining it with the --interactive option explicitly is generally not a good idea unless you know what you are doing (see BUGS below).

git rebase 的原因实际上是在另一个提交之上重播您的提交，因此 merge 被消除了。为了说明原因，我已经复制了您的存储库。

$ 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)

请注意最后一点，“onto 267627b”，这是“added a”提交。这两个提交，“version 1”和“version 2”将在“added a”之上进行修补。结果将是线性的，不需要 merge 。

因为分支，甚至有冲突需要解决。两次提交都从“added a”更改了同一行，因此无论它们以何种顺序完成，它们都会发生冲突。

冲突已解决，这是结果。

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

“版本 1”更改去哪儿了？解决冲突意味着“版本 1”不再有任何更改，因此 rebase 删除了空提交。它这样做是为了避免重新引入可能已经 merge 的提交。您可以使用 --keep-empty 关闭此行为，尽管没有什么理由这样做。

---

如果您确实想保留 merge ，我的建议是首先将您的功能分支 rebase 到 master 之上，然后 merge 并强制 merge 。假设您有这个。

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

首先，将功能 rebase 到 master。

git checkout feature
git rebase master

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

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

一旦功能经过测试，就可以与 master merge 。由于没有对 master 的新更改，通常 merge 会快进导致这种情况。

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

现在很难看出作为功能的一部分进行了哪些更改，这是 future 调试的重要背景。相反，我们希望使用 --no-ff 来保证 merge 提交。

git checkout master
git merge --no-ff feature

结果是这样的:

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

历史是线性的，作为一个分支一起做了哪些提交也一目了然， merge 提交可以用来解释分支。

这是我 merge 功能分支的正常流程。