git 合并与变基

Question

我使用 git 将近 2 年了，现在我很困惑是要重新设置分支还是将分支与 master 合并。

我已经搜索了这个网站，没有发现任何与我的具体原因/论点有关的问题。

我个人从不鼓励任何人重新设置分支。我一直坚持大家把分支合并到master。当然，在一些特殊情况下，除了变基或创建新分支外，我们别无他法，我选择了变基。

我从不鼓励也不主张不要变基的原因是，假设两个开发人员在两个不同的分支上工作。

1. 开发人员一和二签出到新分支。
2. 开发者一提交了一些代码并与 master 合并。
3. 开发人员二有一些本地更改。然后，他使用 master 重新设置分支，然后应用他的更改和提交，然后与 master 合并。

不幸的是，开发人员一引入了一个错误，他的代码失败了。现在开发者二也有这些变化。

除非开发人员一解决该问题，否则开发人员二无法继续。然后开发人员二必须再次变基才能得到修复。

此外，如果开发人员 1 和开发人员 2 正在开发两个不同的功能，如果我们重新设置开发人员的两个分支，反之亦然，两个分支都将包含这两个功能。除了提交的数量也会增加。

假设开发者一为他的功能做了三个提交。在开发人员两次变基后，他将提交他的功能以及开发人员的提交。这将做出更多的提交。

另一方面，如果开发人员 2 必须始终为 master 上的每次合并重新设置基准，那么拥有分支的意义何在？开发者二可以执行以下操作。

1. 他将在 master 上工作。
2. 当他决定推送代码时，他将隐藏更改。
3. 拉取最新更改。
4. 将分支到一个新的分支。
5. 然后弹出更改
6. 修复合并冲突（如果有）
7. 创建一个提交，然后与 master 合并。

这样至少开发者两个不需要总是变基。

在一天结束时，在开发者二将他的代码与 master 合并后，开发者二的分支和 master 是等价的。从技术上讲，有两个名字不同的大师。

这就是我要争论的问题。

但是，我鼓励仅在开发人员二已经分支出来并且几天后基础代码在 master 上进行了很多修改时才进行 rebase，开发人员二正在处理的大部分功能都已更改。然后我认为可以重新设置基础并修复所有冲突并继续前进。

实际上我们遵循敏捷。据我所知，理想情况下，敏捷中不会有两个用户故事在同一个 sprint 中处理相同的功能/代码。因此，如果我们总是选择合并代码而不是变基，那么合并冲突将最少或没有。

最后我想知道开发人员是否必须总是无缘无故地使用 master 变基，或者是否没有经验法则必须总是变基。

变基和合并的优缺点是什么？

提前谢谢大家。如果我问了一个愚蠢/毫无意义的问题，我很抱歉。

Answer 1

合并

• 与 Rebase 相比，使用和理解更简单。
• HEAD 分支将生成一个新的提交，保留每个提交历史的祖先。
• 提交历史记录可能会被大量合并提交污染，因为多个人同时在同一个分支上工作。

变基

• 将一个分支的更改重新写入另一个分支，而不创建新的提交。

• 代码历史简化、线性且可读。

• 变基不适用于拉取请求，因为您看不到有人做了哪些细微的更改。

• 在处理冲突时需要更多的工作。使用 rebase 来更新你的特性分支需要你一次又一次地解决类似的冲突。

• 由于上述声明，您需要更加小心地进行变基而不是合并。

希望这将帮助您解决关于这两个命令的一些疑问。我在this article 中找到了此信息，请务必查看以了解更多详细信息。