Git rebase -i --preserve-merges丢失更改

舍比

我有以下情况：

$ git --version
git version 2.7.3.windows.1

$ git log --graph --oneline
* 83e3254 version 1.1
*   34188af merge of feature into master
|\
| * 784ba31 awesome change
|/
* 6eec273 added file1
* 84d80a5 added version file

将其复制到新目录中

rm -rf .git
git init
echo version 1.0 > version.txt
git add version.txt
git commit -m "added version file"

echo file1 > file1
git add file1
git commit -m "added file1"

git checkout -b feature
echo awesome change >> file1 && git commit -am "awesome change"

git checkout master
git merge --no-ff --no-commit feature
echo "small fixup" >> file1
git commit -am "merge of feature into master"

echo version 1.1 > version.txt
git commit -am "version 1.1"

现在，我看到此功能适用于1.1版。所以我这样做：

git rebase --preserve-merges -i master~3

与此作为git-rebase-todo

pick 6eec273 added file1
pick 83e3254 version 1.1
pick 784ba31 awesome change
pick 34188af merge of feature into master

并得到了：

$ git log --graph --oneline
*   34188af merge of feature into master
|\
| * 784ba31 awesome change
|/
* 6eec273 added file1
* 84d80a5 added version file

83e3254怎么了？我错过了什么吗？需要保留合并内容时，是否应该在todofile中使用34188af？

梅勒比乌斯

这可能与记录的rebase机制的不完善有关。从git rebase文档中：

-p
--preserve-merges
重新创建合并提交，而不是通过重播合并提交引入的提交来变平历史记录。合并冲突解决方案或手动修订以合并提交不会保留。

这在--interactive内部使用机器，但是除非您知道自己在做什么，否则将它与--interactive选项明确组合通常不是一个好主意（请参阅下面的错误）。

在-i和--interactive选项是同义的。

让我们看一下BUGS部分：

呈现的待办事项列表--preserve-merges --interactive不代表修订图的拓扑。编辑提交并对提交消息进行重新措辞应该可以正常工作，但是尝试对提交进行重新排序可能会产生违反直觉的结果。

例如，尝试重新排列
1 --- 2 --- 3 --- 4 --- 5
至
1 --- 2 --- 4 --- 3 --- 5
通过移动“ pick 4”行，将产生以下历史记录：
        3
       /
1 --- 2 --- 4 --- 5