相同点:
-
两者都可以合并代码。
不同点:
-
比如现在在某个子分支执行git rebase(merge) master操作。
-
-
merge:将在子分支的所有提交记录成一次commit,保留在记录中。
-
rebase:不会保留commit记录,直接将分支中的内容排到master的记录之后。
-
最明显的特点就是rebase是一条直线,merge是很多条分支合并在一起。
-
使用场景:
rebase:
-
1、同事修改的模块与自己的模块没有关联,拉取别人修改的模块,合并代码也不会影响功能。
场景一:
一直在某个子分支开发功能。你还没开发完,然后你的同事告诉你,你引用的其他模块的内容有更新,你需要拉取一下最新的master代码更新一下该的模块。
推荐使用rebase。该模块的内容更新和你功能无关,合并代码也不会影响你的功能,无需保留该记录。如果使用merge,在开发周期长的情况下,会创造很多无用的commit记录。
merge:
-
1、多个人开发同一个模块。很可能他的某个改动会导致你的功能出问题,如果出了问题,保留记录能便于后期排查问题
-
2、master分支需要将开发完的子分支的内容合并进来,使用merge可以留有提交记录,出现问题方便后面排查问题
-
场景一:
你和同事两个人在开发同一个模块,你同事开发的部分功能已经合并到了master,通知你更新一下最新的模块代码。
推荐使用merge。你和同事开发的是同一模块,很可能他的某个改动会导致你的功能出问题,如果出了问题,保留记录能便于后期排查问题。(如果从逻辑上可以判断不会有影响,那么使用rebase也可以)
场景二:
现在有个子分支模块已经开发完,master分支需要将这个分支的内容合并进来。
推荐使用merge。使用merge可以留有提交记录,如果该模块出了问题,方便后面排查问题。
使用Rebase要注意:
不要把master rebase进分支里 ,因为这么做并不会改变master任何代码,别人使用的仍然是原始的master。
PS:强推
如果rebase后的分支要推到远端,会由于跟远端commit历史信息产生冲突,而无法推成功。这时候就要用强推git push -f