git am, git apply, git format-patch，git diff 用法

传统的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/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

，带有提交信息的补丁就打好了，可以直接提交了