<万博manbetx平台> Git 合并策略:Git Merge 和 Git Rebase 简介(他们用来做什么以及何时使用它们)-万博manbetx平台

Git 合并策略:Git Merge 和 Git Rebase 简介(他们用来做什么以及何时使用它们)

10年服务1亿前端开发工程师

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

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

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

Git Merge

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


图注:Merge Master -> Feature branch

优点

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

缺点

  • 提交历史记录可能会被许多合并提交污染
  • 使用 git bisect 进行调试会变得更难

怎么做

使用 checkoutmerge 命令将 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 执行后分支的确切内容。通过重新排序实体,可以使历史记录看起来像您想要的任何内容。例如,可以使用 fixupsquashedit 等命令代替 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

赞(5) 打赏
未经允许不得转载:万博manbetx平台 » Git 合并策略:Git Merge 和 Git Rebase 简介(他们用来做什么以及何时使用它们)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

前端开发相关广告投放 更专业 更精准

联系我们

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏