git merge&rebase区别
merge rebase两个分支合并操作,各有利弊;我们先看看表现吧;
假如master和feature分支如下:
如果我们merge操作;
我们看到 合并时候,作为一个新提交作为一个新节点,head指针移动到最新master分支;
feature分支历史被有效的保留着;
优点
简单易上手
保留了提交历史和时间次序
保留了分支的结构
缺点
提交历史被大量的 merge 提交污染了
我们再看看rebase操作;
我们看到rebase后,原先的feature接接到master原先分支前面;
feature分支信息没了;
具体执行操作是 重新提交每一次的本地变化,如果有冲突,需要先解决冲突;
优点
把复杂的历史变成优雅的提交线
操作单个提交变得很简单(比如,reverting)
避免了庞大的仓库、海量的分支以及烦人的 merge 提交
线性合并清除了中间的无用提交,对于 DevOps 团队来说是个好消息
缺点
Rebase 后 feature 分支间的上下文模糊了
在团队里 rebasing 公共分支是高风险的事
具体使用哪种,其实都是可以的,不管用哪种,根据项目管理来约定;
注意点:
假如使用rebase,一定要遵守rebase黄金法则,共享的public分支不能rebase,
通俗的说,当一个分支是一个人开发处理的,才可以rebase,假如一个分支被多个人共享开发,然后rebase,那就乱套了,处理起来复杂;
------------------------------------------------------------------------------------------------------------------------------
作者: java1234_小锋
出处:https://www.cnblogs.com/java688/p/13418946.html
版权:本站使用「CC BY 4.0」创作共享协议,转载请在文章明显位置注明作者及出处。
------------------------------------------------------------------------------------------------------------------------------
回复关键字「666」获取66套Java实战项目视频教程,你要的都有!
回复关键字「全栈」获取Java从入门到大神系列全栈开发教程;
回复关键字「面试」获取一份2020Java笔试面试题;
回复关键字「简历」获取50套Java经典优秀简历模版;
回复关键字「BAT」获取历年来BAT笔试面试题打包合集;