理解git的rebase与merge

·  阅读 232
理解git的rebase与merge

前言

在团队协作中,涉及GitFlow工作流的规范操作,一些分支的命名、合并等。分支合并有两种方式:rebase(变基)和merge。

之前一直都是用merge合并分支,第一次接触rebase的合并分支操作。结合rebase与merge分析他们之间的差异,以及理解‘为什么rebase可以保持branch commit history非常干净’。

理解

现在假设从主分支(origin)切出一条分支(mywork),进行功能开发,同时主分支上也合并了一下别人的修改,这时候两个分支开始‘分叉’了。 image.png

假设现在功能开发完成,需要进行分支合并,用merge进行操作。因为origin分支所在提交不是mywork分支所在提交的直接祖先(Common Ancestor),Git会使用两个分支的末端所指的快照(C4C6)以及这两个分支的公共祖先(C2),做一个简单的三方合并,合并的结果是生成一个新的快照(并提交)。那么分支的情况,如下图: image.png

可以看出merge会保留原来的分支,并且有两个分支的合并点C7,即一个新的“合并的提交”(merge commit)。如果有很多人合作开发,并且都是用merge合并,graph就很乱了。

image.png

那Git的提交历史不能是一条干净的直线?这时候就可以考虑用rebase合并分支了。

它的原理是首先找到这两个分支(即当前分支 mywrok、变基操作的目标基底分支 origin) 的最近共同祖先 C2,然后对比当前分支相对于该祖先的历次提交,提取相应的修改并存为临时文件, 然后将当前分支指向目标基底 C4, 最后以此将之前另存为临时文件的修改依序应用。C5 中的修改变基到 C4 上。 image.png

image.png

image.png

此时,C5'指向的快照和前面C7指向的快照一模一样。这两种整合方法的最终结果没有任何区别,但是变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现,尽管实际的开发工作是并行的, 但它们看上去就像是串行的一样,提交历史是一条直线没有分叉。

变基是将一系列提交按照原有次序依次应用到另一分支上,而合并是把最终结果合在一起。但是缺点就是本地的分叉提交已经被修改过了。

rebase vs merge

Git 是一个非常强大的工具,允许你对提交历史做很多事情。但是每个团队制定的规范、对项目的需求不一样,没有说用哪种方式最优,只要挑选适合团队的方式即可。

  • 观点:

merge:仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档,本身就有价值,不能乱改。 rebase:认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿,软件维护手册也是需要反复修订才能方便使用。

  • 注意:

1、不要在公共分支使用rebase

2、本地和远端对应同一条分支,优先使用rebase,而不是merge

Tip:当在本地开发时,如果时间跨度过长,为了避免提交合并发生冲突,需要偶尔去合并一下dev分支,那么此时用rebase合并,就可以保持commit history的整洁干净,不会有不必要的merge commit信息。

参考

rebase

Rebase - 廖雪峰的官方网站

Git-变基

git rebase 还是 merge的使用场景最通俗的解释

分类:
前端
标签:
分类:
前端
标签: