Git 合并策略：Git Merge 和 Git Rebase 简介（他们用来做什么以及何时使用它们）

小编推荐： 掘金是一个面向 程序员 的高质量技术社区，从 一线大厂经验分享到前端开发最佳实践，无论是入门还是进阶，来掘金你不会错过前端开发的任何一个技术干货。

作为一名开发人员，我们许多时候必须在 Merge和 Rebase 之间进行选择。 我们从互联网上获得的所有参考文档文章，几乎都告诉我们“不要使用 Rebase，它可能会导致严重的问题。”在这里，我将解释什么是 merge 和 rebase，为什么你应该（或者不应该）使用它们，以及如何做。

Git Merge 和 Git Rebase 其实是都是为了完成同样的目的。 它们旨在将来自多个分支的更改集成到一个分支中。 虽然最终目标是相同的，但这两种方法以不同的方式实现。

这个问题在 Git 社区中引起了分歧。有些人认为应该总是使用 rebase ，而另一些人则认为应该总是使用 merge 。双方都有一些令人信服的好处。

Git Merge

对于使用版本控制系统的开发人员来说，merge 是一种常见的做法。不管创建分支是为了测试、修复 bug 还是其他原因，将提交更改合并到另一个位置。 更具体地说，merge 获取源分支的内容并将它们与目标分支集成。 在此过程中，仅更改目标分支。 源分支历史保持不变。

图注：Merge Master -> Feature branch

优点

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

缺点

git bisect

怎么做

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

$ git checkout feature
$ git merge master

(or)

$ git merge master feature

这将在 feature 分支中创建一个新的 合并(Merge)提交 ，其中包含两个分支的历史记录。

Git Rebase

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

与 merge 不同，重定位使历史变得扁平，因为它将完成的工作从一个分支转移到另一个分支。在这个过程中，不需要的历史记录被消除。

Rebases 是更改应从层次结构顶部向下传递的方式，并且 Merge 是它们向上流回的方式

图注：Rebase feature 分支到 master

优点

• 简化可能复杂的历史记录
• 操作单个提交很容易（例如还原它们）
• 避免分支频繁合并提交，频繁回购。
• 通过将它们作为单个提交来清理中间提交，这对DevOps团队很有帮助

缺点

• 将该功能分解为少量提交可以隐藏上下文
• 在团队合作时，重新定位公共存储库可能会很危险
• 可能带来更多的工作：使用rebase 来保持您的 feature 分支始终更新
• 使用远程分支 Rebase 需要强制推送。人们面临的最大问题是他们强制推送，但还没有设置 git push 默认值。这会导致对本地和远程上具有相同名称的所有分支进行更新，这是非常可怕的，并且处理起来非常糟糕。

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

怎么做

使用以下命令将 feature 分支 Rebase 到主分支上。

$ git checkout feature
$ git rebase master

这会将整个 feature 分支移动到主分支的顶部。它通过为 原始(feature)分支中的每个提交创建全新的提交来重写项目历史。

交互式的 rebase

这允许在将提交移动到新分支时更改提交。 这比自动 rebase 更强大，因为它提供了对分支的提交历史的完全控制。 通常，这用于在将 feature 分支合并到主分支之前，清理杂乱的历史记录。

$ git checkout feature
$ git rebase -i master

这将通过打开编辑器，列出即将移动的所有提交。

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

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

我们应该使用哪一个

哪一个最好？ 专家建议什么？

由于每个团队都不同，因此很难概括和哪一个最好。 但我们总得找个地方开始。

团队在设置 Git rebase 与 merge 策略时，需要考虑几个问题。因为事实证明，哪种工作流策略好，这取决于你的团队。

考虑跨组织的重基和Git能力级别。确定相对于可追溯性和合并历史，您更重视重基的简单性的程度。

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

最后，应该在清晰的分支策略的上下文中考虑关于 merge 和 rebase 的决策(请 参阅本文 以了解关于分支策略的更多信息)。成功的分支策略是围绕团队组织设计的。

我推荐什么？

随着团队的增长，使用始终 merge 策略管理或跟踪开发更改将变得非常困难。要有一个清晰易懂的提交历史记录，使用 Rebase 是合理和有效的。

通过考虑以下情况和指南，您可以充分利用 Rebase ：

你在本地开发：如果您还没有与其他人合作。此时，你应该更喜欢 rebase 而不是 merge 以保持历史的整洁。如果您拥有存储库的个人分支并且未与其他开发人员共享，那么即使您已经推送到分支之后，也可以安全地进行 rebase 。

您的代码已经准备好接受评审：您创建了一个 pull 请求。其他人正在评审您的工作，并可能将其提取到他们的分支中进行本地评审。此时，您不应该 rebase 你的工作。您应该创建 rework 提交并更新您的 feature 分支。这有助于拉取请求中的可追溯性，并防止意外的历史记录破坏。

评审已经完成，准备集成到目标分支中。恭喜你!您将要删除您的 feature 分支。考虑到其他开发人员从现在起不会在这些更改中进行获取合并，这是您清理历史记录的机会。此时，您可以重写历史记录并折叠原始提交，并将那些讨厌的’pr rework’和’merge’提交到一小组重点提交中。为这些提交创建显式合并是可选的，但有价值。它记录了该功能何时升级为 master 。

结论

我希望这这篇文章给出了关于 Git merge 和 Git rebase 的一些见解。 merge 与 rebase 策略总是值得商榷。 但也许这篇文章将有助于消除您的疑虑，并允许您采用适合您团队的方法。

英文原文：https://medium.freecodecamp.org/an-introduction-to-git-merge-and-rebase-what-they-are-and-how-to-use-them-131b863785f