像大多数刚接触Git的人一样，我试图破解适用于git merge和git rebase的用例。我想我终于决定，就最终的工作副本状态而言，它们会给你同样的东西。而且，它们都会导致相同的冲突。如果这不正确，请举例说明。
从我的观点来看，使用rebase而不是合并（如果你的更改没有被推或拉）的主要好处是保持历史的线性。我真正不理解的是开发git-rerere背后的原因。
从联机帮助文件中，git-rerere可以帮助您解决之前已解决的冲突。我要提到的例子可以在http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html找到。
如果项目的策略是不经常将更改从主线合并到主题分支（如linux内核），则上面的示例说明要创建“丢弃”合并提交。本质上，将主服务器合并到您的主题中，运行测试以确保一切仍然有效，然后执行“git reset --hard HEAD ^”，基本上抛弃合并提交。稍后，当您创建另一个“一次性”合并提交时，git-rerere会帮助您解决在第一次抛弃合并中已经解决的冲突。
有人可以解释为什么而不是经历创建临时合并提交的所有麻烦，开发人员不会只是将他的主题改为主人吗？这不是git-rebase的重点 - 获取更改，但避免合并？这不是完成同样的事情，并假设没有人拉动你的主题分支变化，这不是一个更简单的方法吗？抛出合并+ git-rerere工作流程是否真的只适用于推送/撤销更改的情况？
最后一个问题 - 引用Linus说：“但是如果我在你的日志中看到很多'合并分支linus'，我就不会拉你了，因为你的树显然有随机的废话，不应该在那里......“Linus也会有不断变质的问题吗？
答案 0 :(得分：23)
你是正确的，变基和合并可以产生相同的最终树。然而，他们产生的历史是非常不同的，版本控制当然都与历史有关。你已经表达了对线性历史的偏好;这在当地规模上确实是可取的，而合并有助于记录功能，错误修正等的更大规模的交互。
你的核心问题（为什么不仅仅是rebase）的简单答案是，有时候分支有一个合适的位置，如果是这样的话，你应该合并，而不是变基。
例如，您可能有一个适用于维护版本以及当前版本的错误修复程序;你想要从最新的提交中分支它，这是两个版本的祖先。你不能沿着主分支或维护分支向前重新分支该分支，或者你不能再将它合并到另一分支。
同样，所有主题分支都从某处开始。在某些时候，您希望保留该历史记录。你提到了其中一个明确的案例（其他人已经完成了你的工作），但它可能不那么明显了。也许有一些与其他功能的交互，也许这个功能有子功能，并且你试图保持整个层次结构。
所以，当然，如果分支是本地的并且没有理由保持其基础固定，那么就像你说的那样简单地重新定义它并完成它。但有时这不是正确的事情。
你的最后一个问题实际上是关于一些非常不同的问题，与合并冲突无关。 Linus说in the context合并不需要完成。这是分支和合并哲学的一个问题。 Junio Hamano就这个问题写了excellent blog post。一个简短的引文总结了手头的主题：
当你将一个主题分支'add-frotz'合并到你的'master'分支时，你显然正在使用新的'frotz'功能，但更重要的是，你声明需要具有'frotz'功能在'主'分支
Linus不希望看到你一直在合并这个名为'linus'的奇怪分支，因为很明显，你并没有合并一些特定主题，这在你的分支中是可取的。您反复将上游分支合并到主题分支中，这完全是错误的方向。你不需要master（或linus）的所有东西来开发你的主题。你应该完成你的主题，然后以另一种方式合并，上游到主人！在主题分支中所有主的内容是不可取的。 （就集成商而言，单个开发人员的主人真的是一个主题分支。）
因此，Linus没有频繁合并的问题;他有无目的和适得其反的合并问题。 （一般来说，如果你确保你的合并是有充分理由的，那么它们就不会经常发生 - 而且它们几乎永远不会是下游合并。）如果你的改变是有充分理由的，那么他们就会创造历史更好，然后它们是好事，无论多么频繁。
答案 1 :(得分：7)
这不是完成同样的事情，并且假设没有人撤回你的主题分支变化，这不是一个更简单的方法吗？抛出合并+ git-rerere工作流程是否真的只适用于推送/撤销更改的情况？
你已经击中了头部。重新绑定对于尚未发布的分支机构有利; rerere对于您已发布的分支（即，对于下游开发人员而言不适合/讨厌的分支）非常有用。
Linus也会遇到不断变换的问题吗？
不，因为重新定位不会导致合并提交，而且从表面上看，您无法看到分支已被重新定位，而您可以轻松查看分支是否已多次合并到另一个分支中。
答案 2 :(得分：0)
每个功能的分支工作流建议有临时集成分支。在这种情况下，如果您进行rebase，则必须对临时分支进行rebase（或pull），这可能会在最终版本中设置不同的checkin。使你的rebase实际上没用。或者就此而言，如果你确实拉动了你的分支，那么这种拉动可能会变得毫无用处。
Rerere虽然有助于减轻反复出现的合并疼痛。