git 工作流 : throwaway merges and git-rerere - what's the point?

Question

像大多数刚接触 Git 的人一样，我在尝试破译适用于 git merge 和 git rebase 的用例时也有过困惑。我想我终于决定，就生成的工作副本状态而言，它们给你的是同样的东西。而且，它们都会导致相同的冲突。如果这不正确，请提供示例以启发我。

在我看来，使用 rebase 而不是 merge (如果您的更改没有被推送或 pull )的主要好处是保持历史线性。我真正不明白的是开发 git-rerere 背后的原因。

根据联机帮助页，git-rerere 应该可以在您尝试解决之前已解决的冲突时为您提供帮助。我将要引用的示例位于 http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html。 .

如果您的项目的策略是不经常将主线的更改 merge 到您的主题分支(如 linux 内核)，则上面的示例表示创建“一次性” merge 提交。本质上，将 master merge 到你的主题中，运行测试以确保一切仍然有效，然后执行“git reset --hard HEAD^”，基本上丢弃 merge 提交。稍后，当您创建另一个“一次性” merge 提交时，git-rerere 会帮助您解决您在第一次一次性 merge 中已经解决的冲突。

有人能解释一下为什么开发人员不经历创建临时 merge 提交的所有麻烦，而是直接将他的主题 rebase 到 master 上吗？这不是 git-rebase 的重点 - 获取更改，但避免 merge 吗？这不是完成同样的事情吗，假设没有人取消您的主题分支更改，这不是一种更简单的方法吗？ throw-away-merge+git-rerere 工作流程真的只适用于推送/pull 更改的情况吗？

最后一个问题 - Linus 被引述说“但是如果我在你的日志中看到很多'Merge branch linus'，我不会从你这里 pull 出来，因为你的树显然有随机垃圾不应该在那里……”Linus 是否也会遇到不断 rebase 的问题？

Answer 1

你说得对， rebase 和 merge 可以产生相同的最终树。但是，它们产生的历史非常不同，版本控制当然是关于历史的。你表达了对线性历史的偏爱；这在局部范围内确实是可取的，而 merge 有助于记录功能、错误修复等更大规模的交互。

对您的核心问题(为什么不只是 rebase )的简单回答是，有时分支的起点是正确的，如果是这种情况，您应该 merge ，而不是 rebase 。

例如，您可能有一个适用于维护版本和当前版本的错误修复；你想从最新的提交中分支它，这是两个版本的祖先。您永远不能沿着 master 或维护分支将该分支向前 rebase ，否则您将无法再将它 merge 到另一个分支中。

同样，所有主题分支都从某个地方开始。在某个时候，您想保留该历史记录。您提到了一个明确的案例(其他人取消了您的工作)，但它可能远没有那么明显。也许与其他功能有一些交互，也许这个功能有子功能，而您正试图保留整个层次结构。

所以，当然，如果分支是本地的，并且没有理由保持其基数不变，那么就像你说的那样，只需将其 rebase 并完成就简单得多。但有时这不是正确的做法。

您的最后一个问题实际上是关于非常不同的事情，与 merge 冲突无关。 Linus 说 in the context 不需要完成的 merge 。这在很大程度上是分支和 merge 哲学的问题。 Junio Hamano 写了一个excellent blog post关于那个问题。总结手头主题的简短引述:

when you merge a topic branch 'add-frotz' to your 'master' branch, you are obviously incorporating the new 'frotz' feature, but more importantly, you are stating that it is desirable to have that 'frotz' feature in the 'master' branch

Linus 不希望看到您一直 merge 这个名为“linus”的奇怪分支，因为很明显您并没有 merge 某些您希望在您的分支中拥有的特定主题。你反复将上游分支 merge 到主题分支，这完全是错误的方向。您不需要 master(或 linus)的所有东西来开发您的主题。你应该完成你的主题，然后以另一种方式 merge 它，向上游 merge 到 master 中!将master 的所有内容 放在您的主题分支中是不可取的。 (就集成商而言，单个开发人员的 master 实际上是一个主题分支。)

因此，Linus 不存在频繁 merge 的问题；他对无目的和适得其反的 merge 有疑问。 (一般来说，如果你确保你的 merge 是有充分理由完成的，它们就不会频繁——而且它们几乎永远不会是下游 merge 。)如果你的 rebases 是有充分理由完成的，并且它们创造了历史更好，那么它们就是一件好事，无论多么频繁。