【问题标题】:How to check for conflicts during interactive git rebase?如何在交互式 git rebase 期间检查冲突?
【发布时间】:2014-08-04 16:40:56
【问题描述】:

我经常在开发过程中使用git rebase -i <ancestor> 对提交进行重新排序,以通过将相关提交分组在一起来清理我经常出现的小提交。然而,我的重新排序有导致合并冲突的趋势,即当后面的块在重叠的早期块之前重新排序时。

有没有办法在启动 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

注意:我只在我的本地仓库中对未推送到公共仓库的提交进行 rebase。我不是在寻找有关最佳做法的建议。

【问题讨论】:

  • 恐怕没有:(
  • 正如 knittl 所说,没有内置任何东西。不过,您可以通过进行建议的重新排序然后运行一系列 git cherry-pick 操作(在分离的 HEAD 上)来查看是否有任何这些操作导致冲突。如果您遇到冲突,那就是您的答案;如果没有,你的结果就是:将分支标签移动到最新分离的 HEAD,你的 rebase 就完成了。 (换句话说,就是去做,看看有没有冲突。)

标签: git rebase


【解决方案1】:

有趣的是,有一个similar question for mercurial,结论和torek的comment类似:需要模拟rebase,看看有没有冲突。

2010 article 也有类似的建议:

查看 master 的修订历史,寻找可能包含重大冲突或代表重大拐点的提交,并围绕它们选择下一个目标提交;

如果您有一堆简单的提交,例如,您可能希望目标是大提交之前的最后一个此类简单提交。
如果你有一大堆毛茸茸的提交,你可能希望每个提交都成为自己的目标/阶段等。

利用您对应用的了解。

【讨论】:

    猜你喜欢
    • 2011-01-08
    • 2021-11-09
    • 1970-01-01
    • 2015-01-29
    • 1970-01-01
    • 1970-01-01
    • 2017-07-14
    • 2014-11-24
    • 1970-01-01
    相关资源
    最近更新 更多