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