标签：
今天主要的工作就是解决平台升级过程中patch冲突问题
--主要的工作流程
1.下载存在patch冲突的项目源码
2.在相应的源码模块下执行git pull命令，确定源码最新
3.在主目录下面执行patch2一下，这时候可以看到有那些patch
4.patch2+序列号，这时候可以看到这个patch中的冲突
5.这个patch2指令以后，会自动生成一个文件confilct_patch_list,进入里面，你会看到所有存在的patch冲突，把这个文件复制一份，以做保留对照
6.从自己的gerrit平台中，找到别人的patch，然后点开里面的cherry-pick，把下面的那条repo fetch ....复制就行了
7.这时候再次执行patch2 ,会再次生成一个confilct_patch_list文件，然后对比两个文件，找到新增加的存在冲突的patch文件
8.原则上来说，这时候你完全是可以通过对比最新源码跟patch进行内容比较来找出冲突，但是，更加快捷的方式是，你使用
git apply patch.name ，这时候存在冲突的地方，会直接给出具体行的代码提示，你点开代码跟patch进行对照就行了
--找到冲突源码以后，这时候修改方法为：
其实，你最先需要的是理解这个patch的作用，根据功能来进行修改
当然，如果你是在完全不理解的情况下，也是可以进行修改的，这时候就是，看你的patch跟最新源码的差异
1.首先找到存在patch冲突的源码位置
2.把需要修改的patch备份，然后删掉存在冲突的patch
3.把删除过后的patch打到源码里面，查看其他patch是否存在冲突(git apply patchname)
4.在源码里面把patch手动输入到源码中（这其实就是自己想要修改的源码内容）
5.这时候你可以直接使用git diff . >filename（当然为了保险起见，你还是可以使用git add . 然后你使用git diff --cached>filename）
6.这时候你就成功的生成了一个新的补丁filename，然后你把vener/vanzo_custom/patch_projects/packages/apps/Dialer 下面的补丁覆盖掉就好了
--怎么修改以后的patch提交
这时候你直接使用指令git push vanzo HEAD:refs/for/(版本号)就可以了
--几个概念理解总结
1.patch
今天对patch算是有点理解了，之前一直是感觉很朦胧，今天算是提醐管顶了。原来，patch其实就是一种代码的替换，我们想要代码实现什么样的修改，但是我们又不想改变代码的通用性，这时候就可以进行patch来实现。它说白了就是，我把一个代码快修改了以后，每当程序编译的时候，编译器自动就把这个patch给替换掉了。今天我们在dapatch的时候，感觉实际上是偷懒了。因为我们借用了git管理中的git diff。而每当我们修改不同的patch的时候，我们都会进行一步操作：cc这个操作就是消除git提交以后放在缓存或者没有提交的面的内容，它的作用就是让我们修改的源码变回原来的样子。这里面，至于编译器是如何识别patch的，主要是通过命名规则，我们的patch命名，如modify_seleteText_size.patchset.mt71_c39_dutar_taiji_gsm ,modify_seletetext_size是对这个patch功能进行的描述，而后面的mt71_c39_dutar_taiji_gsm就是对应的项目名称
--注意点
1.当我们执行patch2的时候，这个命令是在项目的根目录下面执行的，在其他的模块下面执行的话，没有效果，对于git apply是在目标模块文件夹下面。git fetch 则是在ventor下的目标模块下面
2.如果我们在对比两次patch数量的时候，第二次如果比第一次的冲突少，这时候我们是不许要修改的，当然，这种情况是非常少的。多了才说明在我们修改了源码以后，出现了新的patch冲突
3.当我们使用patch2的时候，可能会发现一些模块没有，我们可以用下面的方法进行添加
vim /git vanzo_team /xulei/patch2.py 在all_module_aw里面添加选项就可以了
标签：
原文地址：http://www.cnblogs.com/zhangshuli-1989/p/zhangshuli_ms_141023113.html
