Git打补丁常见问题

　　往往觉得得到某个功能的补丁就觉得这个功能我就已经成功拥有了，可是在最后一步的打补丁的工作也是须要相当慎重的，甚至有可能还要比你获取这个补丁花费的时间还要多。看到好多同行遇到这个问题，且近期自己也花费近20天「获取，打，验证」一个特性功能的补丁。趁热总结一下，知识点可能不多，可是问题是相当棘手的。

$ git apply -h

usage: git apply [options] [<patch>…]

    –exclude <path>      don\’t apply changes matching the given path

    –include <path>      apply changes matching the given path

    -p <num>              remove <num> leading slashes from traditional diff paths

    –no-add              ignore additions made by the patch

    –stat                instead of applying the patch, output diffstat for the input

    –numstat             show number of added and deleted lines in decimal notation

    –summary             instead of applying the patch, output a summary for the input

    –check               instead of applying the patch, see if the patch is applicable

    –index               make sure the patch is applicable to the current index

    –cached              apply a patch without touching the working tree

    –apply               also apply the patch (use with –stat/–summary/–check)

    -3, –3way            attempt three-way merge if a patch does not apply

    –build-fake-ancestor <file>

                          build a temporary index based on embedded index information

    -z                    paths are separated with NUL character

    -C <n>                ensure at least <n> lines of context match

    –whitespace <action>

                          detect new or modified lines that have whitespace errors

    –ignore-space-change

                          ignore changes in whitespace when finding context

    –ignore-whitespace   ignore changes in whitespace when finding context

    -R, –reverse         apply the patch in reverse

    –unidiff-zero        don\’t expect at least one line of context

    –reject              leave the rejected hunks in corresponding *.rej files

    –allow-overlap       allow overlapping hunks

    -v, –verbose         be verbose

    –inaccurate-eof      tolerate incorrectly detected missing new-line at the end of file

    –recount             do not trust the line counts in the hunk headers

    –directory <root>    prepend <root> to all filenames

$ 

第一步检測补丁有无问题

$ git apply –check xxx.patch

能检測出现的问题有下面几种样例：

1. error: cannot apply binary patch to \’xxx\’ without full index line

xxx通常会是bin/png/gif等等二进制文件　详细的原因就是patch中有指明要打上xxx文件，可是这个文件并不包括在这个patch中，不过有一个名字存在当中。遇到这个问题要重视。

2. error: core/java/android/provider/Settings.java: patch does not apply

出现这样的通常会是补丁冲突，这样的通常是强制打上补丁(使用–reject)后依据产生的*.rej文件来手动解决冲突。

3. warning: core/java/android/view/View.java has type 100644, expected 100755

出现这样的警告通常是文件内没有冲突，可是文件的权限发生变动。一般没有影响。

第二步强制打补丁

$ git apply –reject xxx.patch

运行了这一步后会产生什么样的结果，我对第一步的冲突来相应说明。

1.这样的问题通常是制作补丁的开发者没有将二进制文件制作到patch中云，对于这样的情况不会有不论什么的提示，由于patch中源资源文件都没有，Git也没有什么招术来解决。最好的方法是联系补丁提供者。

2.这样的情况是因为git apply是对照补丁中前后几行代码，假设没有出如今目标文件里，那么这就是冲突。这个是比較常常出现的，对于这样的情况会生成*.rej文件，能够find ./ -name *.rej找到这些冲突的补丁，手动打上就好。

3.能够考虑忽略。

眼下就这些，遇到新的问题再补充。

git am -3 -k后假设有冲突，不要运行git checkout。假设不愿意改动冲突文件，佯装改动一下，加入进去才干进行下一步。
git –git-dir=../other_proj_dir/.git format-patch -k -1 –stdout xxxxxxxxxxxxxxxxxx | git am -3 -k
git am相同有–reject选项，加入这个选项能够将能打上的补丁先打上，冲突的文件生成*.rej文件。