传统的patch可能会丢失一些信息，git 提供两种打patch方法， git diff ,
git format-patch,两种的区别在于前者打出来的patch中不带有提交信息，
后者打出来的patch带有提交信息，使用起来更加方便， 但是git format-patch对补丁要求比较严格，
遇到一些冲突就无能为力了，git 提供了一套很好的机制，配合使用git format-patch 和git apply 进行打补丁，
将事半功倍
下面举例说明git 补丁的用法．
1 git apply , git diff 的用法
git diff commit1 commit2 > ~/patch 将commit1~commit2 之间的提交打成补丁．
git apply ~/patch 合并补丁到代码库
当然在合并的时候有冲突，会提示失败，可以 --reject解决
git apply --reject ~/patch 这时候会生成一些xxx.rej的文件，就是冲突的地方，不能合并进库，没有冲突的地方都会合并到库中，根据xxxx.rej 解决冲突， 删除xxx.rej，就可以重新提交了
注意上使用git diff 产生的补丁没有提交信息，要重新提交，通过git apply 打进来的代码，都是相当于新写的代码，可能会比较麻烦，要想生成带有提交信息的补丁，就应该用git format-patch生成补丁
git format-patch commid1 commid2 将commit1~commit2 之间的提交打成补丁．如果相差多条提交 会生成多个补丁，当然也可以合并生成１个补丁 补丁的形式类似于0001-130-sync-disable-Blur.patch 是不是很清晰
git am 0001-130-sync-disable-Blur.patch 进行打补丁，这个就类似于cherry-pick了
当然也可能产生冲突 冲突信息类似下面这样
正应用：130-sync: disable Blur error: 打补丁失败：src/com/letv/android/cloudservice/ui/sync/DataPickFragment.java:293 error: src/com/letv/android/cloudservice/ui/sync/DataPickFragment.java：补丁未应用 补丁失败于 0001 130-sync: disable Blur 失败的补丁文件副本位于： /home/tlinux/ex2/89962/vendor/letv/packages/LetvCloudService/.git/rebase-apply/patch 当您解决了此问题后，执行 "git am --continue"。 如果您想跳过此补丁，则执行 "git am --skip"。 要恢复原分支并停止打补丁，执行 "git am --abort"。
正应用：130-sync: disable Blur
error: 打补丁失败：src/com/xx/xx/xx/xx/xxx/XXX.java:293
error: src/com/xx/xx/xx/xx/xx/XXX.java：补丁未应用
补丁失败于 0001 130-sync: disable Blur
失败的补丁文件副本位于：
/home/tlinux/ex2/xxx/xxx/xxx/xx/xxx/.git/rebase-apply/patch
当您解决了此问题后，执行 "git am --continue"。
如果您想跳过此补丁，则执行 "git am --skip"。
要恢复原分支并停止打补丁，执行 "git am --abort"。
上面的信息很清楚 在/home/tlinux/ex2/xxx/xxx/xxx/xx/xxx/.git/rebase-apply/patch 位置生成了一个path,这个path就是git diff 格式的path,然后就可以通过git apply --reject进行打补丁，
解决冲突后，执行git am --continue，带有提交信息的补丁就打好了，可以直接提交了
