为什么我必须一遍又一遍地解决相同的“git rebase”冲突？答案

【问题标题】：Why do I have to resolve the same "git rebase" conflict over and over?为什么我必须一遍又一遍地解决相同的“git rebase”冲突？
【发布时间】：2012-11-29 06:58:31
【问题描述】：

当我在 branch1-local 中执行 git rebase branch1 时，我会遇到冲突。我解决了冲突，按照 git 的要求执行 git add <conflicted-add>，然后执行 git rebase --continue。之后应用新的提交。新的冲突出现了。但是在同一个文件中又是同样的冲突。我再做一次，git add，git rebase --continue，然后这一切都再次重复，直到我对每个被重新基于的提交重复这个。

为什么 rebase 让我一遍又一遍地重做相同的冲突解决方案？

【问题讨论】：

我从未使用过它，我几乎没有阅读过它的文档，但看看git rerere，AFAIK 用于“记录”冲突解决方案并避免重复它们。查看stackoverflow.com/q/5519244/236871 了解此功能的常见问题。
你有没有弄清楚为什么会这样？我让其他人报告了同样的事情，我希望能够重建这样一种情况，即我必须在变基期间多次应用完全相同的冲突解决方案。
是的，解决方案是永远不要永远再次使用rebase。 pull、merge 和 add 解决就是您所需要的一切
嘿伙计，不要讨厌变基。那东西是金的。
Rebase 基本上很烂，因为它改变了历史并创建了与开发中实际存在的任何状态都不对应的提交（因此从未经过测试）。放弃它是一个不错的选择。 :)

标签： git git-rebase git-merge-conflict

【解决方案1】：

您想要的是git rerere，它会为您记录冲突解决方案。我见过的最好的介绍现在是Git Book, Tools chapter 的一部分。实际上，当您执行变基时，您最终会像以前一样停止，但您只需检查合并冲突是否已解决，然后git add 并继续。

【讨论】：

【解决方案2】：

您不应该一遍又一遍地遇到同样的冲突。 Rerere 在这里帮不了你。 这仅仅意味着你试图重放提交的代码库是如此不同，以至于每个提交都需要你的帮助来调整它。这是赞成合并而不是变基的原因之一。在我看来，rebase 应该只在必要时使用，而不是你常规工作流程的一部分。 Rerere 将在合并/重置类型的工作流程中提供更多帮助。这是我避免变基的工作流程：http://dymitruk.com/blog/2012/02/05/branch-per-feature/

减轻一些痛苦的一种方法是使用像 Beyond Compare 这样的智能合并程序。它具有语法意识，可以解决很多 Git 会（理所当然地）拒绝为你做的冲突。很多时候，这些工具在被调用时甚至不会打开它们的 UI、解决问题并允许您的 git mergetool 命令继续下一个冲突。记得将“trust mergetool exit code”设置为true。

【讨论】：

为了记录，我个人喜欢合并（我已经在其他项目中成功使用过它，并没有太多故障）但是这个新团队想要使用 rebase，因为它使合并树看起来“更整洁”，上帝知道一棵看起来更整洁的树只解决一次冲突（特别是当想要看整洁的树的领导自己没有解决任何冲突时）
那太糟糕了。通常，来自 SVN 背景的 git 新手，其中避免了分支和合并，就像瘟疫一样，他们希望看到一个整洁的历史。 git 的强大之处在于检查图 (DAG)，以查看哪些内容已合并或尚未合并到感兴趣的分支中。你最好的选择是让他们经历所有的冲突解决方案，然后建议尝试一个不依赖 rebase 的工作流程来保持整洁。我的工作流程使事情井井有条。看看他们中的一两个是否会阅读我的帖子。我应该写另一篇文章来解决这个问题。
仅在必要时才应使用变基，而不是常规工作流程的一部分。 -- 这是完全错误的。来自马口：mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
@BenGeorge 我根本没有从 linus 所说的内容中读到这一点。 每个人无论他或她的工作流程如何，都有机会在发布前清理工作。而且我认为将私人工作重新建立在公共分支之上似乎与他的建议一致，尽管我在这一点上并不是 100% 清楚
@Jonah Rebase 以修复三个提交前在您的私有分支中的一些小错误可能是一个非常好的主意（但是，请在每次重写提交时重新运行您的测试套件）。将你的整个分支重新定位到当前的上游开发是临界的（有些人喜欢它，但这意味着，你可能在不知不觉中改变了你所做更改的假设），重新定位已经公开的东西通常是一个非常糟糕的主意（它是直接导致混乱）。在每种情况下，仅当您重新设置基准的原因比可能导致的问题更重要时，才重新设置基准。