git cherry-pick的运用
闲扯几句
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的为准了。至于对同一文件的改动就都还是会产生冲突，需要我们解决冲突，删除文件、新增文件则会直接合并过来。