如果当前提交是合并提交，为什么不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 选项显式结合通常不是一个好主意，除非您知道自己在做什么（请参阅下面的 BUGS）。
原因实际上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)
请注意最后一点，“onto 267627b”，它是“添加的”提交。这两个提交，“版本 1”和“版本 2”将在“添加一个”之上进行修补。结果将是线性的，不需要合并。
由于分支，甚至存在必须解决的冲突。两次提交都从“添加了”更改了同一行，因此无论它们以什么顺序完成，它们都会发生冲突。
冲突已解决，结果如下。
* d6a71b8 (HEAD -> master) version 2
* 267627b added a
“版本1”的变化去哪儿了？解决冲突意味着“版本 1”不再有任何更改，因此 rebase 删除了空提交。这样做是为了避免重新引入可能已经合并的提交。您可以使用 关闭此行为--keep-empty，尽管没有什么理由这样做。
如果您确实想保留合并，我建议首先将您的功能分支重新设置在 master 之上，然后合并并强制合并。假设你有这个。
A - B - C - G - H [master]
\
D - E - F [feature]
首先，将功能重新设置为 master。
git checkout feature
git rebase master
A - B - C - G - H [master]
\
D1 - E1 - F1 [feature]
这导致了线性历史，功能现在在 master 之上，必须解决任何冲突，并且可以使用 master 的所有更新测试功能。
一旦特性被测试，它就可以与 master 合并。由于对 master 没有新的更改，通常合并会快进导致这一点。
A - B - C - G - H - D1 - E1 - F1 [feature]
[master]
现在很难看出作为功能的一部分进行了哪些更改，这是未来调试的重要上下文。相反，我们希望保证与--no-ff.
git checkout master
git merge --no-ff feature
结果是这样的：
A - B - C - G - H ------------ I [master]
\ /
D1 - E1 - F1 [feature]
历史是线性的，也很清楚哪些提交作为一个分支一起完成，合并提交可以用来解释分支。
这是我合并功能分支的正常过程。