正如公认的答案所说,git rebase -i(aka --interactive)支持一个额外的选项-p(aka --preserve-merges)。然而,与公认的答案不同的是,我想指出的是,这实际上似乎可以很好地达到预期的结果,因此,如果您执行git rebase -i -p HEAD~2,合并提交将出现在交互式rebase文件中:
pick abcdeff Merge branch 'feature' into develop
pick abcdefc Extra changes
现在你可以编辑这个重定基文件来标记第二次提交,并完成重定基。看起来一切都很好。 但是,我不明白为什么git文档警告不要使用-i -p(在某些版本的文档中,但不是所有版本的文档中,-p都被弃用了),所以你的里程可能会有所不同。看起来主要的问题是在使用this时试图重新排序提交时出现的...所以不要这样做! 建议使用-p选项的替代选项似乎是git rebase -i -r;但这会产生一个非常长且复杂的交互式rebase文件,它看起来与我所期望的完全不同(即上面所示的简单rebase文件)。 如果有人能给出一个答案,详细解释git rebase -i -p在这种情况下是否合适以及为什么合适,那将是非常有帮助的。
2条答案
按热度按时间nxagd54h1#
所以这里要考虑两个因素:
首先,在某些方面,
rebase
并不总是很好地处理合并提交。第二,我们并不完全清楚你期望的结果是什么。
你是不是想
或
如果您希望得到包含
ABC
的版本,这非常简单。虽然M
没有出现在rebase的TODO列表中,由 *M
带入主线 * 的所有提交(即本例中的A
和B
)是。所以只需将B
和C
标记为"squash"。唯一需要记住的是,这是一次历史重写,因此,如果您已经推送了任何可以到达A
、B
、M
或C
的引用,则可能需要进行一些清理(请参阅"从上游重定基恢复"下的rebase
文档)。如果你想要
MC
的版本,那么问题就很多了,不是说你得不到,而是我不认为你做一个rebase
就能得到;并且MC
也将是"有害合并",这也可能导致与将来的rebase
尝试有关的问题(尤其)。默认情况下,
rebase
会尝试生成线性历史记录,而不会生成合并提交。您可以使用--preserve-merges
选项让它生成合并提交,但这与-i
的交互效果不佳(如果您试图通过这样做来修改合并,我预计可能会出现几个问题)。如果你不担心在合并提交中隐藏修改的问题,并且真的想产生一个类似
MC
的提交,那么方法是:首先,将
master
ref移回M
,同时保留索引中C
的变更。然后将更改直接重新应用于合并提交
lsmepo6l2#
正如公认的答案所说,
git rebase -i
(aka--interactive
)支持一个额外的选项-p
(aka--preserve-merges
)。然而,与公认的答案不同的是,我想指出的是,这实际上似乎可以很好地达到预期的结果,因此,如果您执行git rebase -i -p HEAD~2
,合并提交将出现在交互式rebase文件中:现在你可以编辑这个重定基文件来标记第二次提交,并完成重定基。看起来一切都很好。
但是,我不明白为什么git文档警告不要使用
-i -p
(在某些版本的文档中,但不是所有版本的文档中,-p
都被弃用了),所以你的里程可能会有所不同。看起来主要的问题是在使用this时试图重新排序提交时出现的...所以不要这样做!建议使用
-p
选项的替代选项似乎是git rebase -i -r
;但这会产生一个非常长且复杂的交互式rebase文件,它看起来与我所期望的完全不同(即上面所示的简单rebase文件)。如果有人能给出一个答案,详细解释
git rebase -i -p
在这种情况下是否合适以及为什么合适,那将是非常有帮助的。