Git学习: rebase vs merge

作为开发人员，我们许多人必须在merge和rebase之间进行选择。有了我们从互联网上获得的所有参考，每个人都认为不要使用Rebase，它可能会导致严重的问题。 在这里，我将解释什么是merge和rebase，为什么（不应该）使用它们以及如何使用它们。

Git Merge和Git Rebase具有相同的目的。它们旨在将来自多个分支的更改集成到一个分支中。尽管最终目标是相同的，但是这两种方法以不同的方式实现了目标，当您成为一名更好的软件开发人员时，了解它们之间的差异将很有帮助.

这个问题分裂了Git社区。有些人认为您应该始终rebase，而其他人则应该始终merge。双方都有一些令人信服的好处。

Git merge

对于使用版本控制系统的开发人员而言，merge是一种常见做法。无论是出于测试，错误修复或其他原因而创建分支，都将merge更改提交到另一个位置。更具体地说，merge采用源分支的内容，并将它们与目标分支集成在一起。在此过程中，仅目标分支被更改。源分支历史记录保持不变。

优点

• 简单又熟悉
• 保留完整的历史记录和时间顺序
• 维护分支的上下文

缺点

• 提交历史可能会被很多merge提交污染
• 使用调试git bisect可能会变得更加困难

怎么做

使用checkout和merge命令将master分支merge到feature分支。

$ git checkout feature
$ git merge master

(or)

$ git merge master feature

这将在Feature分支中创建一个新的 merge commit，其中包含两个分支的历史记录。

Git Rebase

Rebase是将更改从一个分支集成到另一个分支的另一种方法。Rebase将所有更改压缩到单个“patch”中。然后，它将patch集成到目标分支上。

与merge不同，rebase使历史变平，因为它将已完成的工作从一个分支转移到另一个分支。在此过程中，消除了不需要的历史记录。

rebase是如何将更改应从层次结构的顶部向下传递，而merge则是更改如何向上传递

优点

• 简单化复杂历史
• 容易操作单个提交（例如revert它）
• 避免在庞大仓库忙碌的分支中存在很多乱七八糟的‘merge’ commit
• 通过清理使多个提交成为单个提交，这对于DevOps团队可能会有所帮助

缺点

• 将功能压缩到少量提交可能隐藏一些信息
• 团队合作时重新建立公共存储库可能很危险
• 更多的任务：要经常使用rebase来使feature分支始终保持更新
• 要通过远程分支进行rebase，您需要强行推送。

如果您错误地进行rebase，并且无意间重写了历史记录，则可能导致严重的问题，因此请确保您知道自己在做什么！

怎么做

使用以下命令将Feature分支重新建立到master分支上。

$ git checkout feature
$ git rebase master

这会将整个功能分支移到master分支的顶部。它通过为原始（功能）分支中的每个提交创建全新的提交来重写项目历史记录来实现此目的。

rebase交互

这允许在将提交移到新分支时更改提交。这比自动rebase功能更强大，因为它可以完全控制分支的提交历史记录。通常，这用于在将功能分支merge到master之前清理混乱的历史记录。

$ git checkout feature
$ git rebase -i master

这将打开editor并列出所有将要移动的commit。

pick 22d6d7c Commit message#1
pick 44e8a9b Commit message#2
pick 79f1d2h Commit message#3

这精确地定义了执行rebase之后分支的外观。通过重新排序实体，您可以使历史记录看起来像您想要的任何东西。例如，你可以用这样的命令fixup，squash，edit等代替pick。

使用哪一个

由于每个团队都不相同，因此很难一概而论并决定彼此。但是我们必须从某个地方开始。

团队在设置他们的Git rebase与merge策略时需要考虑几个问题。因为事实证明，一种工作流程策略并不比另一种更好。这取决于您的团队。

考虑整个组织内的rebase和Git能力水平。确定与可追溯性和merge历史相比，您对rebase的简单性的重视程度。

最后，应在明确的分支策略的背景下考虑merge和重新定级的决策。一个成功的分支策略是围绕团队的组织设计的。

我有什么建议？

随着团队的成长，采用始终merge的策略将难以管理或跟踪开发变更。为了拥有清晰可理解的提交历史，使用Rebase是合理且有效的。

通过考虑以下情况和准则，可以充分利用Rebase：

• 您正在本地开发：如果您尚未与其他人共享您的工作。在这一点上，您应该更喜欢rebase，以保持历史整洁。如果您拥有存储库的个人分支，并且未与其他开发人员共享，则即使您已推送到分支，也可以安全地进行rebase。
• 您的代码已准备好进行review：您创建了pull request。其他人正在review您的工作，并有可能将其拿到他们的分支中进行本地review。在这一点上，您不应该rebase。您应该创建“rework”提交并更新功能分支。这有助于拉取请求中的可追溯性，并防止意外的历史记录损坏。
• review已完成，可以merge到目标分支中,您即将删除功能分支。从现在开始，考虑到其他开发人员将不会进行这些更改的merge，这是您清理历史的机会。此时，您可以重写历史记录并将原始提交以及那些讨厌的 ‘pr rework’ 和“ merge”提交折叠为一小组集中的提交。为这些提交创建显式merge是可选的，但很有用。

结论

我希望这种解释能对Git merge和Git rebase有所启发。merge与rebase策略始终值得商榷的。但是也许本文将有助于消除您的疑虑，并允许您采用一种对您的团队有用的方法。

An introduction to Git merge and rebase: what they are, and how to use them