谈谈有趣的git merge 和 git rebase

本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer,已开源在github ,欢迎star!

转载声明:转载请注明出处,本技术博客是本人原创文章

本文GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收录,这是我花了6个月总结的一线大厂Java面试总结,本人已拿大厂offer,欢迎star

原文链接:blog.ouyangsihai.cn >> 谈谈有趣的git merge 和 git rebase

最近一直在做项目,然后,每天都和git打交道,俗话说:一来生二来熟,每天相拥,不熟也难啊,所以,最近就去看看了两个有趣的git命令,这两个命令可能每个人使用的时候都是不一样的,最开始,我也没有注意这么多,最近才去认认真真的思考了这两个命令的区别,发现了其中的一些奥妙,这篇文章就简单的聊一聊吧。

git merge

最开始的时候,我还是习惯用git merge这个命令的,但是,后来发现很多人其实也用git rebase,所以,就想看看为啥有这两种用法的区别,到底区别在哪里?

先来看看git merge的用法。

我们首先在master的基础上新建分支,然后做一些修改,并且提交。

git checkout -b feat/work
vim service.go
git add .
git commit -m '提交feat/work'
vim service2.go
git add .
git commit -m '提交新增修改'

通过上面的操作,我们在master的基础上进行了分支feat/work创建,并且进行了两次提交,所以,目前的git分支情况应该是下面这样的。

好了,这个时候,这个分支已经开发完了,那么,我们就需要合并分支了,我们进行下面的git merge操作。

但是,这个时候,别人开发完了他的分支之后,也进行了提交,并且merge到了master,这个时候情况如下图。

这个时候,我们再进行merge
的时候就会发现,会有conflict需要我们解决。

git merge解决冲突的方式是一次全部进行递归合并,如果有冲突的文件进行提示,然后需要我们进行修改。修改完了之后,我们再用git addgit commit提交就ok了。

git merge master

我们进行了合并master的操作,这时的情况应该是这样的。

然后,我们再进行master合并feat/work进行快进就可以完成整个过程了。

通过上面的这个实例我们会发现,如上图git merge的操作,是会保留在分支上的所有的提交记录的,这样的好处就是可以保留所有的历史的提交的记录,方便查看历史的log。

ok,下面我们再来看看git rebase的操作是怎么样的。

git rebase

终于等到你,我们来看看git rebase是什么神仙。

同样的,我们还是创建一个新的分支,然后进行一些操作。

git checkout -b feat/work //新建分支
vim service3.go
git add .
git commit -m '提交修改'

同时,别人也新建了一个新的分支进行开发,相当于有两个分支同时进行开发。

git checkout -b feat/work2 //新建分支
vim service3.go
git add .
git commit -m '提交修改'

我们同时对一个文件中的一个方法进行修改,这个时候,然后,另外一个小伙伴进行了merge操作,这个时候的git情况就变成下面这样的了。

这个时候我们进行git rebase会发现有冲突,所以我们需要解决冲突,前面说过,git merge解决冲突是递归合并,然后有冲突的文件全部显示出来,然后自己去解决。而git rebase的解决冲突方式则是一次解决一个,解决完一个再下一个

比如,我们解决第一个,解决完了之后,我们用先用git status查看目前的git情况,然后再添加刚刚解决的冲突 git add u

git status //查看git状态
git add -u

接着,我们用git rebase --continue继续解决冲突。如此反复,最终把全部冲突解决。

另外,如果想中途退出,可以用git rebase --abort命令,退出rebase,这样就会回到rebase之前。

rebase的解决冲突过程可以用如下图表示。

rebase的整个过程,首先会类似将C5、C6复制一份,然后放入到最新的master之后。

然后,再将feat/work分支上的commit全部删除。

整个过程可以用如下图表示。

所以说,rebase会将原来的分支的commit的全部清除掉。

小小对比

通过这两个操作的过程,我们会发现这两个命令的区别。

第一个git merge一次全部解决冲突,git rebase一次解决一个,这种方式会发现,git rebase一次解决一个,不容易漏掉,思路清晰,而git merge的话更快解决。

第二个git merge会保留合并之前分支的所有提交,历史记录更加完整,而git rebase则是直接放到master之后,会清除分支上的所有commit记录,这样好处就是可以使得整个master更加整洁。

那到底用哪一个呢,其实没有最好的办法,两种都是可以的,看你怎么选择,一种可以记录历史分支的提交,另外一种则不记录,但是使得master更加清晰,所以,就看自己的取舍。

git rebase缺陷

最主要的意思就是说,我们在用git rebase的时候,需要注意一点:只对尚未推送或分享给别人的本地修改执行变基操作清理历史, 从不对已推送至别处的提交执行变基操作

具体的问题描述可以看看git的官方文档,非常详细,不过多描述:https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA

本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer,已开源在github ,欢迎star!

转载声明:转载请注明出处,本技术博客是本人原创文章

本文GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收录,这是我花了6个月总结的一线大厂Java面试总结,本人已拿大厂offer,欢迎star

原文链接:blog.ouyangsihai.cn >> 谈谈有趣的git merge 和 git rebase


 上一篇
凉,房子没有抢到? 凉,房子没有抢到?
完了,房子没有抢到。。。 你以为我买房的时候,房子没有抢到吗,那你就错了,我哪有这个实力买房子,哈哈。 最近不是来深圳鹅厂实习了嘛,来的时候也没有考虑这么多,没有什么经验,租了一个35平方的房子,你想想在深圳这个10w一平的城市,一个月的
下一篇 
在鹅厂工作的一天 在鹅厂工作的一天
来腾讯实习已经好多天了,今天跟大家谈谈在腾讯工作的一天的感受。 早上上班走起第一天上班,总是想早点去的,就跟小时候上学一样,第一天充满激情,打了鸡血一样;同样,第一天去公司也是早早 9 点就出发了,可是,天有不测风云,意想不到的事情发生了,