git - 如果我们在 Git 中将提交压缩为一个并变基，那么变基或合并真的很重要吗？

Question

我们变基的原因是历史都是线性的。但是，如果我们将提交压缩为一个，那么我们只是合并然后忽略任何分支是否重要？

我正在和一位同事讨论如果历史是线性的，并且如果一个开发人员有 7 次提交并且 7 次提交中的 1 次提交引入了一个错误，我们可以使用自动二进制搜索准确找到它是哪个提交（并且自动化测试）。但他说，如果一些中间提交实际上还不是很好，它可能会破坏构建或破坏测试。然后他提到能够将所有提交压缩成一个并且只是变基，那么它就不会有捕获不太准备好的提交这样的问题。

如果我们真的可以使用二分搜索来找到哪个提交引入了一个新的错误，那就太好了，我们不必担心历史有 7 倍的提交，因为当 n 为时 O(log n) 不是问题增加了 7 倍——这仅仅意味着 3 次构建和测试。但是我们真的在实践中使用自动构建和自动测试来进行二进制搜索以找到新的错误吗？看起来真的很费时间。

如果我们只是合并然后完全忽略任何分支，那不就和 squash 和 rebase 一样吗？当我们忽略任何分支（只是一条直线）时，有一个额外的合并提交是相同的形状，与我们只是将所有提交压缩为一个并重新设置基准相比。

标签： gitmergerebase

Answer 1

如果您压缩提交，那么无论您是变基还是合并都无关紧要。它们将产生相同的树，因为变化是相同的。如果您使用 GitHub 等功能齐全的 Git 服务器，您会发现 squash 工作流程被称为“squash and merge”，但行为是相同的。

正如您已经注意到的那样，不压缩的好处是您可以非常精确地平分引入错误的更改。但是，您也可以使用不会压缩的常规合并工作流程来执行此操作，因为git bisect知道如何处理合并提交就好了。

为了从这个额外的历史中获得真正的好处，您通常必须拥有一个具有健全、合乎逻辑、可对分提交的工作流。如果你有很多我们称之为“修复提交”的东西来修复语法错误或其他错误，并且不强制执行理智的、合乎逻辑的提交，那么git bisect将很难追踪有问题的提交，因为有些提交甚至不会构建。因此，如果您想采用它，您必须在代码审查中甚至在 CI 中强制执行此策略。相反，压缩的好处是开发人员可能很懒惰，但代价是潜在的巨大的、难以理解的代码转储为单个提交。

在使用 Git 时，我们确实经常使用它git bisect来追踪有问题的提交。我还在以前的工作场所使用它来追踪我们引入回归的位置，所以这是一种广泛使用的方法。然而，有些项目不关心哪里出了问题，也不使用reverts，所以他们用git bisect的不多。这取决于您的项目和工作流程，以及您团队的文化。

一旦我看到可行的方法是要求理智的、合乎逻辑的、可对分的提交或挤压。如果您是一个细心、有条不紊的开发人员，愿意在合并之前进行 rebase 并获得提交，那么您可以直接合并它们；如果你想偷懒，那你就得打壁球。这保留了分支的平分性，同时使不太挑剔的开发人员更容易。如果您愿意，也可以使用 rebase 来代替这种方法。

我的一般方法是 Git 方法（这应该不足为奇，因为我为 Git 做出了贡献）：将功能分支重新设置为合理的逻辑提交，然后创建合并提交。但最终，您必须选择适合您团队的工作流程。