~技术问答题~
返 回

No.736 什么时候使用“git rebase”代替“git merge”?

题目描述~ 略...

寄语:问题比答案更重要

建议自己先有个思考的过程,有了自己的答案或者疑问再看解析进行对比。

目前解析在逐步添加中,也可以跳转链接查看。

这两个命令都是把修改从一个分支集成到另一个分支上,它们只是以非常不同的方式进行。

考虑一下场景,在合并和变基前:

A <- B <- C    [master]

^


  D <- E       [branch]

在 git merge master 之后:

A <- B <- C

^         ^



  D <- E <- F

在 git rebase master 之后:

A <- B <- C <- D <- E

使用变基时,意味着使用另一个分支作为集成修改的新基础。

何时使用:

如果你对修改不够果断,请使用合并操作。

根据你希望的历史记录的样子,而选择使用变基或合并操作。

更多需要考虑的因素:

分支是否与团队外部的开发人员共享修改(如开源、公开项目)?如果是这样,请不要使用变基操作。变基会破坏分支,除非他们使用 git pull --rebase,否则这些开发人员将会得到损坏的或不一致的仓库。

你的开发团队技术是否足够娴熟?变基是一种破坏性操作。这意味着,如果你没有正确使用它,你可能会丢失提交,并且/或者会破坏其他开发者仓库的一致性。

分支本身是否代表有用的信息?一些团队使用功能分支(branch-per-feature)模式,每个分支代表一个功能(或错误修复,或子功能等)。在此模式中,分支有助于识别相关提交的集合。在每个开发人员分支(branch-per-developer)模式中,分支本身不会传达任何其他信息(提交信息已有作者)。则在这种模式下,变基不会有任何破坏。

是否无论如何都要还原合并?恢复(如在撤销中)变基,是相当困难的,并且/或者在变基中存在冲突时,是不可能完成的。如果你考虑到日后可能需要恢复,请使用合并操作。

解析或答案仅供参考。

关于作者

zz_jesse 专注前端

掘金 我的开源项目

公众号@前端技术江湖

一个可以帮开发者成长的公众号前端面试题库更新通知前端学习资料、干货文章

技术交流群

交流中成长大厂内推机会