没有“正确”的方法：Git Rebase 与 Merge

Rebase 和 Merge 的工作原理

合并

变基

我的 Rebase 与 Merge 策略

没有“正确”的方法

为了庆祝我的新车牌，我决定写一篇简短的文章，介绍一下 rebase 和 merge 的区别，以及它们各自的工作原理，以及我是如何选择使用它们的。我们先来了解一下它们的工作原理。

Rebase 和 Merge 的工作原理

首先，我们有两个分支。一个是主分支，另一个是我们刚从主分支切下来的 Feature 2 分支。这两个分支都如下所示。由于我们刚切下来的 Feature 2 分支与主分支完全相同，所以目前没有任何变化。

几天后，我们的 Feature 2 分支上有一些新的提交，其中包含已完成的新功能工作。

在同一天，主分支也从另一位参与该项目的开发人员那里添加了一些新的提交。

现在我们准备测试 Feature 2 分支了，但在测试之前，我们需要确保它已更新到 master 分支中的所有新代码。为了将 master 分支中的新更改更新到 Feature 2 分支，我们有两个选择：合并 (merge) 或变基 (rebase)。

合并

合并命令将让我们获取主分支上的所有开发更改，并通过单个合并提交将它们集成到 Feature 2 分支中。

单个合并提交涵盖了主分支的所有更改。合并的一个缺点是，如果你的主分支非常活跃，它可能会严重污染你的功能分支的历史记录。如果你不希望功能分支的历史记录中包含合并提交，那么你可能需要考虑使用变基。

变基

我们可以使用 rebase 命令将 master 分支的更改集成到 Feature 2 分支中，通过重写提交历史记录来生成连续的提交。Rebase 操作会将整个 Feature 2 分支移动到 master 分支的末端。

如您所见，没有多余的提交，所有内容都排列整齐，就好像我们刚刚在新的主分支顶部添加了功能 2 提交一样。

我的 Rebase 与 Merge 策略

说到变基与合并，我会在不同场景下使用它们。当我需要更新我正在 master 分支上进行的功能分支时，我总会使用变基。我选择这样做是因为我喜欢清晰的分支历史记录。如果所有提交都是新代码，我更容易阅读和跟踪。当需要将分支更改合并到 master 分支时，我会使用合并。我喜欢这样做，因为这样我就能得到一个包含所有分支更改的单一提交，并且很容易找到。

根据我的经验，在团队开发代码库时，将功能分支合并到主分支时进行合并是最常见的做法。至于如何更新您自己的功能分支，通常由您自己决定，这也引出了我的下一个观点。

没有“正确”的方法

变基 vs 合并是开发社区中一个由来已久的争论，就像制表符 vs 空格一样。同样，就像制表符 vs 空格一样，变基 vs 合并也没有绝对正确的方法。有些人坚持认为必须使用合并。另一些人则认为唯一正确的方法就是变基。猜猜怎么着，两者都没有对错之分！如何使用变基 vs 合并，完全取决于你和你的工作流程。

同样的概念也适用于许多常见的开发争论，例如一行代码应该包含多少个字符，一个方法应该包含多少行等等。通常，当你学习新东西时，你想知道的只是“正确”的做事方法。你总是希望有人告诉你该怎么做。不幸的是，这并不总是那么容易。当你刚开始的时候，不要寻找正确的方法，而要寻找最适合你的方法。每个人都有自己的风格和最高效的工作方式。环顾四周，学习其他开发人员的做法，但最终还是要自己决定哪种方法最有效。

您还能想到哪些其他“开发辩论”，其中两种方式都可行，而选择哪一种只是个人偏好？