我在使用长 rebase 时遇到的一个问题是必须解决冗余冲突。假设我有一个分支，其中包含一系列不断修改函数的提交，而最终提交完全删除了该函数。
当我执行 rebase master 时，Git 天真地依次应用每个提交。这意味着我需要在 master 的提示下解决这些提交中的每一个 - 即使最终这些工作被浪费了。
处理这种情况的好方法是什么？也许我应该只为整个分支生成一个补丁，然后将其应用于 master？如果是这样，有没有办法保留一些历史？想法、建议等
最佳答案
您想使用 git rerere结合使用 rerere-train.sh 从历史提交中教授 rerere 数据库(您可能已经在 /usr/share/doc/git/contrib/rerere-train.sh 中找到它)。这允许 git 自动使用从历史中学习的 merge 冲突解决方案。
警告:您基本上是通过盲目地使用历史字符串替换来修复冲突的 merge ，让 git 重写源代码。您应该在 rebase 之后查看所有冲突的 merge 。我发现 gitk 对此工作正常(它将仅显示冲突解决作为 merge 补丁)。我对 rerere 只有很好的体验，你可能没那么幸运。基本上，如果您的历史记录确实包含损坏的 merge (即技术上不正确完成的 merge ，然后在后续提交中修复)，您不想使用历史记录中的 rerere，除非您想要自动为您完成类似的中断 merge 。
长话短说，你只要跑
git config --global rerere.enabled 1
bash /usr/share/doc/git/contrib/rerere-train.sh --all
然后是您真正想做的 rebase ，它应该会神奇地起作用。
全局启用rerere后，以后就不需要再学习历史了。只有在启用 rerere 之前冲突解决已经完成之后，才需要使用 rerere 学习功能。
附言。我找到了另一个问题的类似答案:https://stackoverflow.com/a/4155237/334451
关于git - 更聪明的 rebase 避免冗余工作？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10601541/