更聪明的rebase避免多余的工作？

Question

我遇到长期重组的一个问题是必须解决多余的冲突.假设我有一个带有一系列提交的分支,它们不断修改一个函数,最后的提交完全删除了该函数.

当我这样做时rebase master,Git天真地依次应用每个提交.这意味着我需要使用master的提示解决每个提交 - 即使最终这些工作被浪费了.

处理这种情况的好方法是什么？也许我应该为整个分支生成一个补丁,并将其应用于master？如果是这样,有什么方法可以保留一些历史记录吗？思想,建议等

Answer 1

您希望git rerere结合使用rerere历史提交来教授数据库rerere-train.sh(您可能已经拥有它/usr/share/doc/git/contrib/rerere-train.sh).这允许git自动使用从历史记录中学习的合并冲突解决方案.

警告:你基本上是通过盲目地使用历史字符串替换来修复冲突的合并,使git重写源代码.您应该在rebase之后查看所有冲突的合并.我发现它gitk可以正常工作(它将仅显示冲突解决方案作为合并的补丁).我只有很好的经历rerere,你可能没那么幸运.基本上,如果您的历史确实包含已损坏的合并(即,技术上不正确的合并然后在以下提交中修复),您不希望rerere在历史记录中使用,除非您希望为您自动完成类似的破坏合并.

长话短说,你就跑了

git config --global rerere.enabled 1
bash /usr/share/doc/git/contrib/rerere-train.sh --all

接下来是你真正想做的事情,它应该只是神奇地工作.

在rerere全局启用后,您不再需要从将来的历史中学习.只有rerere在启用之前已经完成冲突解决的事实之后才需要学习功能rerere.

PS.我找到了另一个问题的类似答案:https://stackoverflow.com/a/4155237/334451

Answer 2

你可以使用git rerere功能.

您必须启用它git config --global rerere.enabled 1,之后,您解决的每个冲突都会被存储以供以后使用,并且在相同的上下文中重新应用解析.

您可以使用检查存储的分辨率git rerere diff.

有关更多信息,请查看本教程.

Answer 3

为什么不在squash初始交互式 rebase 中将冗余补丁放在一起（首先将它们重新排序，以便它们在一起），以便您清除序列的“修改然后删除”方面。在此阶段，您可以选择提交中的大块头（例如使用 git gui）。然后，这将为您提供更好的序列，以进行最终干净的变基。