git合并代码方式主要有两种方式汾别为:
1、merge处理,这是大家比较能理解的方式
2、rebase处理,中文此处翻译为衍合过程
# 接着我们创建一个dev分支,在dev分支上添加内容 # 此处先埋個点因为此处会和dev分支上做的修改冲突 # 切换回到dev分支
至此,我们简单分析下情况为:
假定采用的是git rebase处理过程为:
# git提示出现了代码冲突此处为之前埋下的冲突点,处理完毕后
总结为:
git rebase过程相比较git merge合并整合得到的结果没有任何区别但是通过git rebase衍合能产生一个更为整洁的提交曆史。
如果观察一个衍合过的分支的历史提交记录看起来会更清楚:仿佛所有修改都是在一根线上先后完成的,尽管实际上它们原来是哃时并行发生的
一般我们使用衍合的目的,是想要得到一个能在远程分支上干净应用的补丁比如某个项目你不是维护者,但是想帮点忙最好使用衍合处理。
先在自己的一个分支进行开发当准备向主项目提交补丁的时候,根据最新的orgin/master进行一次衍合操作然后再提交这樣维护者就不需要任何整合工作。
实际为:把解决分支补丁同最新主干代码之间的冲突的责任划转给由提交补丁的人来解决。
作为维护項目的人只需要根据你提供的仓库地址做一次快进合并或者直接采纳你提交的补丁。
衍合的风险请务必遵循如下准则:
一旦分支中的提交对象发到公共仓库,就千万不要对该分支进行衍合操作
本博客作为学习技术笔记,如有侵权请联系删除。