19

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

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

从手册页来看， git-rerere 应该在您尝试解决之前解决的冲突时为您提供帮助。我将要参考的示例位于http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html。

如果您的项目的策略是不要不断地将来自主线的更改合并到您的主题分支（如 linux 内核），那么上面的示例说创建“丢弃”合并提交。本质上，将 master 合并到您的主题中，运行测试以确保一切仍然有效，然后执行“git reset --hard HEAD^”，基本上将合并提交扔掉。稍后，当您创建另一个“一次性”合并提交时，git-rerere 会帮助您解决您在第一次一次性合并中已经解决的冲突。

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

最后一个问题 - 引用 Linus 的话说：“但如果我在你的日志中看到很多 'Merge branch linus'，我不会拒绝你，因为你的树显然有随机的废话，不应该在那里……”Linus 是否也会遇到不断变基的问题？

4

3 回答 3

24

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

对您的中心问题（为什么不只是变基）的简单回答是，有时有一个分支开始的正确位置，如果是这种情况，您应该合并，而不是变基。

例如，您可能有一个适用于维护版本和当前版本的错误修复；您希望从作为两个版本的祖先的最新提交中分支它。您永远不能沿着主分支或维护分支向前重新设置该分支，否则您将无法再将其合并到另一个分支中。

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

所以，当然，如果分支是本地的并且没有理由保持其基础固定，那么正如您所说的那样，只需重新设置它并完成它就更简单了。但有时这不是正确的做法。

您的最后一个问题实际上是关于一些非常不同的事情，与合并冲突无关。Linus 说，在不需要进行合并的情况下。这在很大程度上是分支和合并哲学的问题。Junio Hamano 写了一篇关于这个问题的优秀博客文章。简短的引述总结了当前的主题：

当您将主题分支 'add-frotz' 合并到您的 'master' 分支时，您显然是在合并新的 'frotz' 功能，但更重要的是，您表示希望在 '师父分行

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

所以，Linus 不存在频繁合并的问题；他对无目的和适得其反的合并有问题。（一般来说，如果你确保你的合并是有充分理由的，它们就不会频繁——而且它们几乎永远不会是下游合并。）如果你的 rebase 是有充分理由完成的，那么它们就会成为历史更好，那么它们是一件好事，无论多么频繁。

于 2010-06-18T18:36:17.973 回答
7

这不是完成同样的事情，并且假设没有人拉动您的主题分支更改，这不是一种更简单的方法吗？throw-away-merge+git-rerere 工作流程真的只适用于您的更改被推/拉的情况吗？

你一针见血了。变基适用于尚未发布的分支；rerere对于您已发布的分支很有用（即，对于下游开发人员来说，变基不合适/烦人的分支）。

Linus 也会有不断变基的问题吗？

不，因为变基不会导致合并提交，而且从表面上看，您看不到一个分支已经变基，而您可以很容易地看到一个分支是否已多次合并到另一个分支中。

于 2010-06-18T18:35:48.287 回答
0

每个功能工作流的分支建议有临时集成分支。在这种情况下，如果您重新设置基准，您将不得不针对临时分支重新设置基准（或拉取），该临时分支可以在最终版本中设置不同的签入设置。让你的变基实际上毫无用处。或者就此而言，如果您确实拉入了您的分支，那么该拉动可能会变得毫无用处。

不过，Rerere 将极大地帮助缓解反复出现的合并痛苦。

于 2015-08-02T07:55:08.390 回答