优秀的编程知识分享平台

网站首页 > 技术文章 正文

learnGit-代码合并merge和rebase总结「转」

nanyue 2024-12-11 16:11:04 技术文章 6 ℃

“合并代码”绝对是高危中的高危工作,如果团队没有注意分支管理,或者团队成员没有及时同步分支的习惯,或者不恰当地使用了回滚、合并等操作,那么合并代码时大概率会出现各种冲突,甚至代码”丢失“。之前就有经历过,折腾了很久,反而更糟糕,仓库代码支离破碎,堪称”事故现场“,幸亏有位同事Git用得贼溜,一番操作,成功解决问题,实在是大写地佩服!!![666]

鉴于此,虽不求精通Git,但为了自己还有同事的幸福[无辜笑],还是好好了解下Git吧。

完整的原理和基本操作建议参考官方文档或阮一峰博客,learnGit主要结合自己遇到的情况以及我认为值得重点关注的点做下整理回顾。比如:常见的问题和解决、一些方便高效的操作习惯、进阶操作、团队开发使用规范等。

来自B站的视频,地址

https://www.bilibili.com/video/BV1cv411u7wd#reply109308251840

1.1 介绍

Merge和Rebase是合并两个分支的操作。都是checkout到某个分支上,然后把别的分支合并到该分支。

其中,Merge在没有分叉的情况下,会自动使用fast-forward的方式,快速移动

Merge在有分叉的情况下,会产生一个新的提交点,(--no-ff)他就是别的分支多次commit的合并:

Rebase叫做变基。也是把别的分支合到自己身上,但是效果就好像在基的基础上重新提交自己的多次commit。看起来就好像重新从基抽出来一次:

把自己的提交(2-3)顶到最后面

1.2 异同

? 作用大体相同

都是把别的分支合到自己身上。别的分支不会改变,变的只是自己

? 效果有些不同

对于merge branch,它是把branch的多次提交合成一个commit,然后加在自己分支的后面。(2-3-6)6就是4和5合成的一个新的提交点。自己的提交(45)在前面,别人的合并在后面。

对于Rebase branch,它就好像在branch(基)的基础上,重新提交自己的多次commit。(4-5-2-3)看起来就好像重新从基抽出来一次。

自己的提交总是在最后面。而且不会多出一个提交点。

? 使用场景不同

1. 当我们在分支future上添加了新功能时,我们直接在主分支master上,Merge一下future,就把新功能加上了。(future你是否继续开发无所谓)。这就是我们的FristProject和SecondProject:在公共分支master上Merge别的功能分支

2. 当我们在功能分支future上开发开发开发,提交提交提交,这个过程中,有人动了主分支master,你想要把这个更改同步到你的future分支上,你选择Rebase master。这样的话你的几个commits就一直处于你分支的最后面。这就是我们的ThirdProject:在开发分支上Rebase主分支,主要是为了和上游分支同步

3. 当然你也可以选择在你的功能分支future上,Merge别的分支。这时候别的分支的commits就作为一个新的提交点跑到你的多次commits的后面了。如果你无所谓顺序,那么可以选择Merge。这对应我们的FourthProject:在开发分支上Merge别的分支

4. 切记:不要在公共分支master上Rebase!!!

因为Rebase之后,master上的多次提交会被顶到别的分支的后面,这就相当于篡改了历史!别人从3这个地方拉出去的,结果你一下子把3给顶到最后面了,那就乱套了。

总结一下:

1、公共分支上选择Merge(将新功能整合到master上)

2、功能分支上选择Rebase主分支(和公共分支同步,把自己的提交顶到最后)

3、功能分支上选择Merge(把别的分支的功能加到自己身上,如果你不介意顺序的话)

4、切记不要在公共分支上Rebase任何分支!

? 优缺点

也谈不上什么优缺点。在适合的场景使用适合的方式。(1、2)

对于3这种情况,比如你要把future开发分支上的新功能导到test测试分支里面去,你可以切到test,然后Merge一下future。因为是测试分支,你没有必要把非要把test的提交顶到最后,于是你就可以选择Merge,而且多出一个节点,用于记录。这是Merge的小优点

当然你也可以选择Rebase一下future,这样的话,你test分支上的多次commit就还是在最后,便于你回退。这是Rebase的优点。(如果使用Merge的话,由于尾巴是future的合并,你再想回退到你test上的某次提交,那就有点麻烦了)。

1.3 特别说明

? 切记不要在公共分支上Rebase任何分支!

(这我们已经解释过)

? 本地和远端对应同一条分支,优先使用Rebase而不是Merge

什么意思呢?

我们刚刚演示所用到的分支都是本地上的两个分支。

当我们从远端orgin/master 拉取(pull)的时候,或者在pycharm、IDEA里面选择Update Project的时候,它总是提示你选择Merge还是Rebase:

可是你想,我就一个master分支啊,远程也是master分支呀,怎么就涉及到合并分支的操作了?

其实是这样的:

git有本地仓库的概念,本地的master是一个仓库,远程的master也是一个仓库,git pull == git fetch + git merge,也就是说,这里让你选择的是,将远程的master拉取下来之后,如何和你的本地master合并?

我们推荐使用Rebase:站在你本地master分支上,Rebase一下远程master。这样的话你刚刚在本地master所做的多个提交,依然会被顶在你本地master分支的最后面。便于你回退。

Tags:

最近发表
标签列表