使用git v1.7.1，我试图同时使用--preserve-merges和--onto功能进行重新基础。最终结果似乎没有合并提交，因此看起来是线性的。我宁愿保留合并提交，原因与人们经常使用--preserve-merges的原因相同（更容易看到在逻辑上是一个单独的功能并在其自己的分支中开发的提交组）。
我的主分支机构（再基地的目的地）很无聊：
A-B-C
我想从中提取的功能分支有一个子功能分支，它已经合并到其中
X - Y
/
V-W ------ Z
其中Z是合并提交，它是要从中获取的功能分支的头，X和Y在子功能分支上。
我正在使用：git rebase --preserve-merges --onto C V Z
我想以结束
X - Y
/
A-B-C-W ------ Z
但我得到的却是：
A-B-C-W-X-Y
由于Z是一个无冲突的合并，所以代码的最终状态是正确的，但历史并不像我希望的那样具有表达性。
有办法得到我想要的吗？
编辑地址@Bombe：我已经编写了一个bash脚本来构建我的示例。在我的系统（RHEL 6.2和git 1.7.1）上，这说明了我的问题。
#! /bin/bash
# start a new empty repo
git init
# make some commits on the master branch
git checkout master
touch A.txt; git add A.txt; git commit -m "add A.txt"; git tag Atag
touch B.txt; git add B.txt; git commit -m "add B.txt"; git tag Btag
touch C.txt; git add C.txt; git commit -m "add C.txt"; git tag Ctag
# now build the feature branch
# start at Btag (more or less arbitrary; point is it's before C)
git checkout Btag
git checkout -b feature
touch V.txt; git add V.txt; git commit -m "add V.txt"; git tag Vtag
touch W.txt; git add W.txt; git commit -m "add W.txt"; git tag Wtag
# now a subfeature
git checkout -b subfeature
touch X.txt; git add X.txt; git commit -m "add X.txt"; git tag Xtag
touch Y.txt; git add Y.txt; git commit -m "add Y.txt"; git tag Ytag
# merge the subfeature into the feature
# preserves branch history with --no-ff
git checkout feature
git merge --no-ff subfeature
# the merge commit is our Z
git tag Ztag
# one more commit so that merge isn't the tip (for better illustration of Z missing later)
touch postZ.txt; git add postZ.txt; git commit -m "add postZ.txt"; git tag postZtag
# now do the rebase
git rebase --preserve-merges --onto Ctag Vtag
# optionally move the master branch forward to the top of feature branch
git checkout master
git merge feature
在重新基准之前我得到：
X-Y
/
V-W-----Z-postZ
/
A-B-C
在重新基准后，我得到：
X-Y
/
V-W-----Z-postZ
/
A-B-C-W'-X'-Y'-postZ'
请注意，在Y'和postZ'之间缺少Z'。
非常感谢Bombe和一位离线朋友指出这对一些人来说确实有效。有了这种灵感，我现在能够回答我自己的问题了。
简言之：1.7.5.2之前的git版本将表现出这种不良行为。
长话短说：在git自己的源代码回购中，2011年4月28日提交c192f9c865dbdae48c0400d717581d34cd315fb8明确解决了这个问题。
引用承诺信息（黄宏发）：
git-rebase--interactive.sh: preserve-merges fails on merges created with no-ff 'git rebase' uses 'git merge' to preserve merges (-p). This preserves the original merge commit correctly, except when the original merge commit was created by 'git merge --no-ff'. In this case, 'git rebase' will fail to preserve the merge, because during 'git rebase', 'git merge' will simply fast-forward and skip the commit. For example: B / A---M / ---o---O---P---Q If we try to rebase M onto P, we lose the merge commit and this happens: A---B / ---o---O---P---Q To correct this, we simply do a "no fast-forward" on all merge commits when rebasing. Since by the time we decided to do a 'git merge' inside 'git rebase', it means there was a merge originally, so 'git merge' should always create a merge commit regardless of what the merge branches look like. This way, when rebase M onto P from the above example, we get: B / A---M / ---o---O---P---Q
解决方案：获取git的新版本，如果需要，可以从源代码构建。
顺便说一句，我用git bisect来解决这个问题。很棒的工具。
我遇到了这个问题。注意我的git版本，它是1.7.10.2。
我正在将提交范围（由其SHA1哈希标识）重新绑定到分支上，并且还缺少最后一次合并提交。
我的解决方案是将W到X的基重定到C上（不使用--preserve合并），然后将Y、Z和postZ的基重设到X'上（使用--present合并）。
希望这能有所帮助。
我刚刚试图重现您的情况，我可以报告--preserve-merges似乎像广告中所说的那样工作。当你在提交Z时，只需发布：
git rebase --preserve-merges --onto C V
这就是我所做的，它保留了合并提交。