一般情况下的问题
我担心一个类似的问题:重新定位整个子历史——几个分支,它们之间的一些链接是由合并产生的:
A--B-B2-B3 <--topicB
\ /
\-C-C2-C3 <--topicC
如果我依次运行多个git rebase(针对 topicB 和 topicC),那么我怀疑是否可以正确保留分支之间的合并。所以我需要一次重新设置所有分支,希望这样可以正确重建它们之间的合并。
适用于特定子案例的“解决方案”
就我而言,我很幸运 topicC 实际上被合并到 topicB:
A-B-----------B2-B3 <--topicB
\ /
\-C-C2-C3 <--topicC
所以要重新定义整个子历史,我可以运行
git rebase -p A topicB --onto A*
(其中A* 是新的基础,而不是A,就像您的问题一样;topicB 是最初指向旧提交 B3 和之后重写的提交 B3' 的分支名称; -p 是 --preserve-merges 选项的简称),获取如下历史记录:
A-B-----------B2-B3
\ /
\-C-C2-C3 <--topicC
A*-B'-------------B2'-B3' <--topicB
\ /
\-C'-C2'-C3'
然后将所有剩余的分支引用(和标签)重置为新的相应提交(在新的子历史中),例如
git branch -f topicC C3'
成功了:
A*-B'-------------B2'-B3' <--topicB
\ /
\-C'-C2'-C3' <--topicC
(移动分支引用和标签也许可以完成with a script。)
受特定案例启发的一般案例的“解决方案”
如果topicC 没有合并到topicB 中,我可以创建一个虚假的顶级提交来合并所有我想变基的分支,例如:
git checkout -b fake topicB
git merge -s ours topicC
然后以这种方式变基:
git rebase -p A fake --onto A*
并将主题分支重置为新的提交,删除假分支。
其他答案
我相信 the other answer 和 --committer-date-is-author-date 也是好的和明智的,但是根据我使用 Git 的经验,我没有这个想法并解决了在变基后保持共享历史真正共享的问题,我的方式已在我的附加答案中进行了描述。