Git下merge与rebase区别与选择

之前pull代码时一直使用merge,遇见了冲突也就直接解决,这样做还算平安。但最近加入一个项目,Team人数,提交Code次数都偏多,这样拉取代码,出现冲突的频率也就很高。使用Merge的话,log点线图就会出现多条线,然后来回合并的情况,很混乱。

针对这情况,Team提倡使用rebase方式拉取代码,但这样好在哪呢,这里查了些资料,整理下。

创建分支

Git因为有了分支,使得我们可以并行进行许多feature的开发,并且互不干扰。在完成后,利用MR来合并到主干分支,比如dev或者master.

合并分支

我们以分支的模式进行开发,然后希望将开发的功能代码放进到主干,这个办法就是合并,在GitLab里叫做MR。

啰嗦下,Git是分布式的,所以比如我们提交的上游服务器存在多条分支,我们每个人的开发机上也会是多条分支,分支合并不仅仅指origin上的A与B的合并,其实我们本地分支提交到上游对应分支,也是一次分支合并。

分支冲突处理

冲突起源是代码之前修改的地方在同一位置,这时,其实Git也不知道该要谁的,所以才会让你去操作,比如accept theirs,yours,或者两者手动去结合下。

merge方式处理冲突

merge方式合并分支,并不保留merge分支的commit,比如下图,棕色的是sprint27,而紫色的是master,合并过来其实之算作一次merge-commit

rebase方式处理冲突

rebase方式合并分支,会将合并分支的commit都合并到目标分支线上,并且也不会创建新的提交

假设合并前是这样:

merge合并后:

rebase合并后:

习惯使用rebase经常拉取代码之后,现在项目上的线就基本就是条笔直的线了,每次谁提交,提交了什么, 简单明确。

写在最后

  • Git这家伙,玩的越多越觉得它简单,强大和灵活。对于它的理解也在实践中不断强化。我司有人说过,一个复杂的东西,做成简单的样子来使用,这才难,我觉得Git就是这样。
  • 针对rebase还是merge操作,与几个好友聊天及结合团队情况,觉得以下实践较佳
    • 获取远程项目代码时,使用 git pull -- rebase
    • 合并分支,使用git merge --no-ff,创建一个merge commit

参考

Donate comment here