本文转载自：http://blog.csdn.net/xzongyuan/article/details/9425739

git format-patch相对于git diff更便于操作，是更新的打包方式，应该采取这种打包方式。git diff打包的patch只能使用git apply处理。而git format-patch的补丁，可以应当使用git am命令。

基本用法

git format-patch xxxx.patch

第一种 

format-patch可以基于分支进行打包，也可以基于上几次更新内容打包。

基于上几次内容打包

git format-patch HEAD^  有几个^就会打几个patch，从最近一次打起

git format-patch HEAD^^ 最近的二个patch内容

以下代码作用同上

git format-patch -1 

git format-patch -2

git format-patch -1 -4    //可以打包版本2,3的patch。但是发现有时候会把最近4个包都打包出来，具体原因未知。

参考：http://leave001.blog.163.com/blog/static/16269129320126944238969/

关于分支，可以参考：http://www.cnblogs.com/y041039/articles/2411600.html

第二种

git format-patch -M origin/master

format-patch 命令依次创建补丁文件,并输出文件名。上面的 -M 选项允许 Git 检查是
否有对文件重命名的提交。我们来看看补丁文件的内容:

[cpp] 
view plain
 copy  

1. $ cat 0001-add-limit-to-log-function.patch  
2. From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001  
3. From: Jessica Smith <jessica@example.com>  
4. Date: Sun, 6 Apr 2008 10:17:23 -0700  
5. Subject: [PATCH 1/2] add limit to log function  
6. Limit log functionality to the first 20  
7. —  
8. lib/simplegit.rb |  
9. 2 +-  
10. 1 files changed, 1 insertions(+), 1 deletions(-)  
11. diff –git a/lib/simplegit.rb b/lib/simplegit.rb  
12. index 76f47bc..f9815f1 100644  
13. — a/lib/simplegit.rb  
14. +++ b/lib/simplegit.rb  
15. @@ -14,7 +14,7 @@ class SimpleGit  
16. end  
17. def log(treeish = ‘master’)  
18. –  
19. +  
20. command(“git log #{treeish}”)  
21. command(“git log -n 20 #{treeish}”)  
22. end  
23. def ls_tree(treeish = ‘master’)  
24. —  
25. 1.6.2.rc1.20.g8c5b.dirty  

如果有额外信息需要补充,但又不想放在提交消息中说明,可以编辑这些补丁文件,
在第一个 — 行之前添加说明,但不要修改下面的补丁正文,比如例子中的 Limit log
functionality to the first 20 部分。这样,其它开发者能阅读,但在采纳补丁时不会将
此合并进来。

应用patch

[cpp] 
view plain
 copy  

1. $ git am 0001-limit-log-function.patch  
2. Applying: add limit to log function  

你会看到它被干净地应用到本地分支,并自动创建了新的提交对象。

有时,我们也会遇到打不上补丁的情况。这多半是因为主干分支和补丁的基础分支相差太远,但也可能是因为某些依赖补丁还未应用。这种情况下,git am 会报错并询问该怎么
做:

[cpp] 
view plain
 copy  

1. $ git am 0001-seeing-if-this-helps-the-gem.patch  
2. Applying: seeing if this helps the gem  
3. error: patch failed: ticgit.gemspec:1  
4. error: ticgit.gemspec: patch does not apply  
5. Patch failed at 0001.  
6. When you have resolved this problem run “git am –resolved”.  
7. If you would prefer to skip this patch, instead run “git am –skip”.  
8. To restore the original branch and stop patching run “git am –abort”.  

Git 会在有冲突的文件里加入冲突解决标记,这同合并或衍合操作一样。解决的办法也一样,先编辑文件消除冲突,然后暂存文件,最后运行 git am –resolved 提交修正结果

[cpp] 
view plain
 copy  

1. $ (fix the file)  
2. $ git add ticgit.gemspec  
3. $ git am –resolved  
4. Applying: seeing if this helps the gem  

如果想让 Git 更智能地处理冲突,可以用 -3 选项进行三方合并。如果当前分支未包含该补丁的基础代码或其祖先,那么三方合并就会失败,所以该选项默认为关闭状态。一般来
说,如果该补丁是基于某个公开的提交制作而成的话,你总是可以通过同步来获取这个共同祖先,所以用三方合并选项可以解决很多麻烦:

[cpp] 
view plain
 copy  

1. $ git am -3 0001-seeing-if-this-helps-the-gem.patch  
2. Applying: seeing if this helps the gem  
3. error: patch failed: ticgit.gemspec:1  
4. error: ticgit.gemspec: patch does not apply  
5. Using index info to reconstruct a base tree…  
6. Falling back to patching base and 3-way merge…  
7. No changes — Patch already applied.  

像上面的例子,对于打过的补丁我又再打一遍,自然会产生冲突,但因为加上了 -3 选项,所以它很聪明地告诉我,无需更新,原有的补丁已经应用。
对于一次应用多个补丁时所用的 mbox 格式文件,可以用 am 命令的交互模式选项 -i,这样就会在打每个补丁前停住,询问该如何操作:

[cpp] 
view plain
 copy  

1. $ git am -3 -i mbox  
2. Commit Body is:  
3. ————————–  
4. seeing if this helps the gem  
5. ————————–  
6. Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all  

在多个补丁要打的情况下,这是个非常好的办法,一方面可以预览下补丁内容,同时也可以有选择性的接纳或跳过某些补丁。
打完所有补丁后,如果测试下来新特性可以正常工作,那就可以安心地将当前特性分支合并到长期分支中去了