如何用git命令生成Patch和打Patch

最新推荐文章于 2024-09-07 09:43:24 发布

qianxuedegushi

最新推荐文章于 2024-09-07 09:43:24 发布

阅读量1.7k

点赞数 1

分类专栏： git

原文链接：https://www.cnblogs.com/ArsenalfanInECNU/p/8931377.html

版权

git 专栏收录该内容

17 篇文章 0 订阅

订阅专栏

转自：https://www.cnblogs.com/ArsenalfanInECNU/p/8931377.html

https://www.jianshu.com/p/ec04de3f95cc

有改动。

在程序员的日常开发与合作过程中，对于code生成patch和打patch(应用patch)成为经常需要做的事情。

什么是patch?简单来讲,patch中存储的是你对代码的修改
什么是生成patch?生成patch就是记录你对代码的修改并将其保存在patch文件中
什么是打patch?打patch就是将patch文件中对代码的修改，应用到源代码，从而把对代码的修改应用到code中。

一、 patch 和diff 的区别

Git 提供了两种补丁方案，一是用git diff生成的UNIX标准补丁.diff文件，二是git format-patch生成的Git专用.patch 文件。
.diff文件只是记录文件改变的内容，不带有commit记录信息,多个commit可以合并成一个diff文件

eg：

git diff  2a2fb4539925bfa4a141fe492d9828d030f7c8a8  89aebfcc73bdac8054be1a242598610d8ed5f3c8 > patch.diff

.patch文件带有记录文件改变的内容，也带有commit记录信息,每个commit对应一个patch文件。

在Git下，我们可以使用.diff文件也可以使用.patch 文件来打补丁，主要应用场景有：CodeReview、代码迁移等。

尽管本身Linux命令里也有diff和patch两个命令可以生成patch和打patch。但是有两个缺点值得注意：

1. 对单个文件或者多个文件，diff和patch这两个文件比较方便。对于git这种以project为单位的修改，尤其是涉及到多个文件夹下的多个文件的改动时，就很不方便

patch命令打patch：（patch，是打补丁的命令，有很多用法，见帮助#man patch）

     由于patch文件的首行已经指明了路径，所以根据patch(单个文件或者包)当前所在的目录，加不同的参数使用patch命令：
1).如果patch(单个文件或者包)当前的目录是和要打进patch的文件是同级目录如当前的目录为 linux-2.6.12：
      [root@kcn-110mw]#patch -p0 < /path/to/isp1161-2.6.12.patch
   2).如果patch(单个文件或者包)当前的目录为 linux-2.6.12/:
     [root@kcn-110mw]#patch -p1 </path/to/isp1161-2.6.12.patch
   3).如果patch(单个文件或者包)当前的目录为 linux-2.6.12/drivers/：
    [root@kcn-110mw]#patch -p2 </path/to/isp1161-2.6.12.pathc

0,1,2,是指略去的patch文件中的前几级目录。

2. 无法保存commit的信息。

因此，推荐大家使用git的format-patch和am命令进行生成patch和打patch，用此方法获得的patch其实就是commit里提交的code修改以及commit信息。有如下好处：

1. 对于git这种以project为单位的修改，尤其是涉及到多个文件夹下的多个文件的改动时，非常方便，能够记录所有的改动（添加，修改，删除文件等）

2. 可以保存commit信息。

3. 能够灵活的获取patch。可以获取任意两个commit之间的patch集。

使用方法（直接给一些examples）：

$ git am --abort # 当git am失败时，用以将已经在am过程中打上的patch废弃掉(比如有三个patch，打到第三个patch时有冲突，那么这条命令会把打上的前两个patch丢弃掉，返回没有打patch的状态)。使用git am之前，要首先git am --abort 一次，来放弃掉以前的am信息，这样才可以进行一次全新的am。不然会遇到这样的错误：
.git/rebase-apply still exists but mbox given.

git format-patch

$ git format-patch HEAD^ 　　　　　　　　　　　　　 #生成最近的1次commit的patch

$ git format-patch HEAD^^　　　　　　　　　　　　　 #生成最近的2次commit的patch

$ git format-patch HEAD^^^ 　　　　　　　　　　　　　#生成最近的3次commit的patch

$ git format-patch HEAD^^^^ 　　　　　　　　　　　 #生成最近的4次commit的patch

$ git format-patch <r1>..<r2> #生成两个commit间的修改的patch（包含两个commit. <r1>和<r2>都是具体的commit号)

e.g.,

git format-patch  2a2fb4539925bfa4a141fe492d9828d030f7c8a8..89aebfcc73bdac8054be1a242598610d8ed5f3c8

$ git format-patch -1 <r1> #生成单个commit的patch

$ git format-patch -n <commit sha1 id> #某次提交（含）之前的n次提交

$ git format-patch <r1> #生成某commit以来的修改patch（不包含该commit）

$ git format-patch --root <r1>　　　　　　　　　　　　 #生成从根到r1提交的所有patch

git format-patch生成的补丁文件默认从1开始顺序编号，并使用对应提交信息中的第一行作为文件名。如果使用了-- numbered-files选项，则文件名只有编号，不包含提交信息；如果指定了--stdout选项，可指定输出位置，如当所有patch输出到一个文件；可指定-o <dir>指定patch的存放目录；

$ git apply --stat 0001-limit-log-function.patch 　　　　 # 查看patch的情况

E.g.,

ator@atorpc:~/workspace/soft/git_org_kernel/linux-stable$ git apply --stat ./patches/*.patch
include/soc/at91/atmel_tcb.h | 183 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 183 insertions(+)
drivers/clocksource/Kconfig           |    8 +
drivers/clocksource/Makefile          |    3
drivers/clocksource/timer-atmel-tcb.c | 410 +++++++++++++++++++++++++++++++++
3 files changed, 420 insertions(+), 1 deletion(-)
drivers/clocksource/timer-atmel-tcb.c | 217 +++++++++++++++++
1 file changed, 212 insertions(+), 5 deletions(-)
drivers/clocksource/Kconfig           |    5
1 file changed, 4 insertions(+), 1 deletion(-)
arch/arm/mach-at91/Kconfig            |   25 ++
1 file changed, 25 insertions(+)
arch/arm/configs/at91_dt_defconfig    |    1
arch/arm/configs/sama5_defconfig      |    1
2 files changed, 2 deletions(-)
arch/arm/configs/at91_dt_defconfig    |    1
arch/arm/configs/sama5_defconfig      |    1
2 files changed, 2 insertions(+)
drivers/irqchip/irq-gic-v3-its.c      |   80 ++++--

。。。。。。

$ git apply --check 【path/to/xxx.patch/diff】 # 检查patch/diff是否能够打上，如果没有任何输出，则说明无冲突，可以打上

e.g., git apply --check 0001-limit-log-function.patch 　

$ git am #可以一次合并一个文件，或者一个目录下所有的patch
$ git am 0001-limit-log-function.patch # 将名字为0001-limit-log-function.patch的patch打上

$ git am ~/patch-set/*.patch　　　　　　　　　　　　　# 将路径~/patch-set/*.patch 按照先后顺序打上

【注：git apply是另外一种打patch的命令，其与git am的区别是，git apply并不会将commit message等打上去，打完patch后需要重新git add和git commit，而git am会直接将patch的所有信息打上去，而且不用重新git add和git commit,author也是patch的author而不是打patch的人。E.g.,

$ git apply #可以一次合并一个文件，或者一个目录下所有的patch

$ git apply 0001-limit-log-function.patch # 将名字为0001-limit-log-function.patch的patch打上

$ git apply ~/patch-set/*.patch　　　　　　　　　　　　　# 将路径~/patch-set/*.patch 按照先后顺序打上

ator@atorpc:~/workspace/soft/git_org_kernel/linux-stable$ git apply ./patches/*.patch
ator@atorpc:~/workspace/soft/git_org_kernel/linux-stable$】

$ git am --resolved #当git am失败，解决完冲突后，这条命令会接着打patch

如果打Patch的过程中发生了冲突（conflicts），怎么办？

解决patch冲突的过程是：

如果不想打这一系列patch了，直接：git am --abort回退打入patch的动作，还原到操作前的状态。

也可以执行 git am --skip 跳过此次冲突

如果还想打, 有两种解决方案：

方案一（个人推荐）：

(1) 根据git am失败的信息，找到发生冲突的具体patch文件，然后用命令git apply --reject <patch_name>，强行打这个patch，发生冲突的部分会保存为.rej文件（例如发生冲突的文件是a.txt，那么运行完这个命令后，发生conflict的部分会保存为a.txt.rej），未发生冲突的部分会成功打上patch。

(2) 根据.rej文件，通过编辑该patch文件的方式解决冲突。

(3) 废弃上一条am命令已经打了的patch：git am --abort

(4) 重新打patch：git am ~/patch-set/*.patch

方案二：

(1) 根据git am失败的信息，找到发生冲突的具体patch文件，然后用命令git apply --reject <patch_name>，强行打这个patch，发生冲突的部分会保存为.rej文件（例如发生冲突的文件是a.txt，那么运行完这个命令后，发生conflict的部分会保存为a.txt.rej），未发生冲突的部分会成功打上patch。

(2) 根据.rej文件，通过编辑发生冲突的code文件的方式解决冲突。

(3) 将该patch涉及到的所有文件（不仅仅是发生冲突的文件）通过命令 git add . 将所有改动都添加到暂存区（缓冲区）中。

(4) 告诉git冲突已经解决，继续打patch: git am --resolved (和 git am --continue是一样的)

分析：方案一和方案二主要区别是解决冲突的方法不一样。方案一是通过编辑patch文件的方式解决冲突，方案二通过编辑冲突code文件的方式解决冲突。这两种方案区别比较大：经过实验，核心区别在于，方案二无法验证冲突有没有切实的解决。即使你在方案二的第二步乱改一通，也能“打完”发生冲突的patch（并没有检测修改后的code文件跟patch期望的是否相同）。因此，如果采用方案二，那么再解决code文件冲突后，需要人工去确认修改的正确性。

中间如果处理乱了，用 git reset 恢复即可，所以合并 patch 在一个“干净”的分支上处理更好。

关于冲突解决详情可以参考git am冲突解决