merge和rebase的区别
-
采用merge和rebase后,git log的区别,merge命令不会保留merge的分支的commit:
-
处理冲突的方式:
- (一股脑)使用
merge
命令合并分支,解决完冲突,执行git add .
和git commit -m'fix conflict'
。这个时候会产生一个commit。 - (交互式)使用
rebase
命令合并分支,解决完冲突,执行git add .
和git rebase --continue
,不会产生额外的commit。这样的好处是,‘干净’,分支上不会有无意义的解决分支的commit;坏处,如果合并的分支中存在多个commit
,需要重复处理多次冲突。
- (一股脑)使用
-
git pull
和git pull --rebase
区别:git pull
做了两个操作分别是‘获取’和合并。所以加了rebase就是以rebase的方式进行合并分支,默认为merge。
git merge
和 git merge --no-ff
的区别
1、我自己尝试merge
命令后,发现:merge时并没有产生一个commit。不是说merge时会产生一个merge commit吗?
注意:只有在冲突的时候,解决完冲突才会自动产生一个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,便于管理(这看管理人员怎么认为了)