开启成长之旅!这是我参加「日新方案 12 月更文应战」的第3天,点击查看活动概况
闲扯几句
git现在在我们的日常开发作业中能够说是常用的了,可是简直大多数都是只会用到最根底的那么几个指令操作,pull、push、clone、commit、add、status等。至于分支的兼并操作,或许直接说触及到兼并操作用到的简直都很少。可能一些运营开源项目或许一些其它场景的pr(pull request)人员会非常的熟悉。
在看git官网的《progit.pdf》一书中看到过关于git cherry-pick <SHA>
的介绍。
从上图的意思是:会将提交记载直接搬迁过来,就好像你在现在的根底之上做了想要兼并的提交记载的更改,然后进行了提交相同。
然后也在一次作业中偶然的遇到一个需求将另外一个分支的某两个提交记载的改动拿过来,这时候想试试这个操作,可是毕竟是公司的项目库房,在自己不确定的状况下不能乱来,可是又不想一个一个文件的去人为的去搬迁。所以就自己先整个测试库房实验一下。
测试需求考虑的状况
- 兼并对两个提交记载的影响
- 两个提交记载中都有的文件,其间触及修正同一行,新增行,删去行:aa.txt删去行、bb.txt修正、新增行
- main分支提交中删去一个dev分支与main分支都存在的文件:.gitignore文件
- main分支提交中添加一个dev分支中没有的文件:dd.txt文件
- 兼并对两个提交记载之前的作业树(git库房的作业目录)的影响
- 同提交记载相同,作业树中的文件差异也可分为main分支作业树相对于dev分支作业树同文件的行增修改:readme.md改,ee.txt删、ff.txt增
- main分支作业树添加文件:gg.txt
根据以上的考虑状况,做如下的环境预备:
预备好的git测试库房:
兼并提交记载
切换到dev分支后执行git cherry-pick 6691194
,其间6691194
是想要兼并到dev分支的main分支提交记载的哈希值。
处理抵触(挑选某一份更改或许兼并,我这里挑选main分支的更改):
处理结束抵触之后,add文件,然后填写commit信息提交提交,发生一个新的提交记载。
兼并后的状况
从上图中能够看到,兼并会发生一个新的提交记载,假如有抵触的话,就需求手动处理抵触,处理抵触之后就需求从头将修正抵触后的文件添加到暂存区,然后进行提交。假如两次提交记载的改动没有抵触的话,那这种兼并也将会非常的顺畅,就像在此根底之上commit相同。
最终看看兼并后作业树各个文件的状况吧:
总结一下
cherry-pick的兼并确实像官方所说,只会将要兼并的提交记载所触及的文件变化兼并过来,不会触及到提交记载之前的作业树,至于删去行的aa.txt文件没受影响猜想应该是main分支提交记载中它是一个空文件,所以就以dev的为准了。至于对同一文件的改动就都还是会发生抵触,需求我们处理抵触,删去文件、新增文件则会直接兼并过来。