git rebase 和 git merge 区别
在合并分支时,git rebase 会将分支的 commit 信息一并合如 master 分支 , 而 git merge 不会,它会在主分支外保留其他分支的 commit 信息 。rebase 和 merge 的提交历史图将分支删除后 ,两种情况下的 commit 信息都不会消失 , 但是 git merge 会留下合并分支的记录 。rebase 和 merge 删除分支后的区别一直在使用这两个命令,但对两者之间的细节没有在意过,今天受启发,具体的研究一下 。
个人爱好: 为保证代码提交历史的条理性,建议使用 git rebase 操作 。
git rebase 使用步骤
分支 master 和 branch (当前分支 master)
git rebase branch
编辑过程中存在冲突,解决完冲突后,执行:git add xx
继续变基git rebase --continue
查看代码树git log --graph
概述
一直以来对git的rebase和merge命令都有点混淆,刚好有朋友问到这一块,所以也抽空去整理了下这方面内容,以作备忘!
merge和rebase
git的merge和rebase都是用来合并分支的。
这里不多解释rebase命令,以及两个命令的原理,下面主要说的是两者在实际操作中的区别。
什么是分支
分支就是便于多人在同一项目中的协作开发。比方说:每个人开发不同的功能,在各自的分支开发过程中互不影响,完成后都提交到develop分支。极大的提高了开发的效率。
合并分支
每个人创建一个分支进行开发,当开发完成,需要合并到develop分支的时候,就需要用到合并的命令。
什么是冲突
合并的时候,有可能会产生冲突。
冲突的产生是因为在合并的时候,不同分支修改了相同的位置。所以在合并的时候git不知道那个到底是你想保留的,所以就提出疑问(冲突提醒)让你自己手动选择想要保留的内容,从而解决冲突。
merge和rebase的区别
1、采用merge和rebase后,git log的区别,merge命令不会保留merge的分支的commit:
2、处理冲突的方式:
(一股脑)使用merge命令合并分支,解决完冲突,执行git add .和git commit -m'fix conflict'。这个时候会产生一个commit。(交互式)使用rebase命令合并分支,解决完冲突,执行git add .和git rebase --continue,不会产生额外的commit。这样的好处是,‘干净’,分支上不会有无意义的解决分支的commit;坏处,如果合并的分支中存在多个commit,需要重复处理多次冲突。3、git pull和git pull --rebase区别
git pull做了两个操作分别是‘获取’和合并。所以加了rebase就是以rebase的方式进行合并分支,默认为merge。
git merge 和 git merge --no-ff的区别
1、只有在冲突的时候,解决完冲突才会自动产生一个commit。
如果想在没有冲突的情况下也自动生成一个commit,记录此次合并就可以用:git merge --no-ff命令,下面用一张图来表示两者的区别:
2、如果不加 --no-ff 则被合并的分支之前的commit都会被抹去,只会保留一个解决冲突后的 merge commit。
如何选择合并分支的方式
我的理解:主要是看那个命令用的熟练,能够有效的管理自己的代码;还有就是团队用的是那种方式。
我对于rebase比较熟悉,所以我一般都用rebase,但是现在的公司用的是merge --no-ff命令合并分支。所以,我在工作上就用merge,个人项目就用rebase。
也可以两者结合:
获取远程项目中最新代码时:git pull --rebase,这个时隐性的合并远程分支的代码不会产生而外的commit(但是如果存在冲突的commit太多就像上面说的,需要处理很多遍冲突)。合并到分支的时候:git merge --no-ff,自动一个merge commit,便于管理(这看管理人员怎么认为了)总结
其实看懂上面的两幅图就行了。注意两点:commit log的区别和处理冲突的方式。
后面会分享更多devops和DBA方面的内容,感兴趣的朋友可以关注一下~
上一篇: 从什么时候开始,你害怕过生日了
发表评论