我经常使用 git rebase -i <ancestor>
在开发过程中重新排序提交,通过将相关提交分组在一起来清理我经常使用的小提交。但是,当较晚的大块在重叠的较早的大块之前重新排序时,我的重新排序往往会导致 merge 冲突。
有没有办法在启动 rebase 之前评估特定订单是否会发生冲突?
例子:
$ git rebase -i 800adf8
# Interactive Rebase
pick 800adf8 initial commit
pick 2647ae9 content: add header <--+
pick b0a2be6 content: add navbar | hunks overlap
pick 8b86f8a header: add stylesheet <--+
pick 1da6209 content: add footer
pick 7d55152 header: add jquery
pick 515c410 content: add form
# After reorder
pick 800adf8 initial commit
pick 8b86f8a header: add stylesheet <-- conflict
pick 7d55152 header: add jquery
pick 2647ae9 content: add header <-- conflict
pick 1da6209 content: add footer
pick b0a2be6 content: add navbar
pick 515c410 content: add form
注意:我只对未推送到公共(public)仓库的本地仓库中的提交进行 rebase 。我不是在寻找有关最佳实践的建议。
最佳答案
有趣的是,有一个 similar question for mercurial , 结论类似于 torek的 comment : 需要模拟rebase,看看有没有冲突。
这2010 article有一个类似的建议:
Review the revision history of master, look for commits likely to contain significant conflicts or representing significant inflection points, and pick your next target commit around them;
if you have a pile of simple commits, you might want the target to be the last such simple commit prior to a big one, for instance.
If you have a bunch of big hairy commits you may want each to be its own target/stage, etc.Use your knowledge of the app.
关于git - 如何在交互式 git rebase 期间检查冲突?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25123508/