很失败，工作三年多了，才会用git am相关指令，而且一直自诩从事linux驱动、内核开发的老手，哎！
本文作为自己对自己这几年来混吃等死的批判。
此处说明的是，在看完该文后，回头看这些内容：
补丁可能是自己弄的或者是从社区获取的，不管是哪种，都需要添加上自己的信息，
自己做的话，在git commit的时候可以：
git commit -s #就可以将自己相关信息 signed off上去。
从社区或者别处获取的，在打上去的时候，可以
git am -s #通过这种方式，同样就将自己信息signed off上去了。
git format-patch制作patch常用的几种格式
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号) git format-patch -1 <r1> #生成单个commit的patch git format-patch <r1> #生成某commit以来的修改patch（不包含该commit） 此处表示的是最新的commit到自己前面一个commit的所有patch git format-patch --root <r1> #生成从根到r1提交的所有patch
需要说明的是，git format-patch head^指令虽然正宗，但是输入指令个人还是觉得比较麻烦的，你可以直接采用如下指令生成patch：
git format-patch -1 #生成当前commit的patch
git format-patch -8 # 生成最新8个commit的patch,注意顺序，最新的commit的patch编号一定是0008-xxxx
git format-patch cover-letter制作补丁说明
补丁制作完成后，需要你的上级或者同事审查，这种情况下，你该怎么制作补丁呢？？？，你可以通过git format-patch --cover-letter -8指令，制作8个补丁，并包含一个0000开头的patch
介绍该8个补丁的改动情况。
打开该文件，你可以看到对这8个patch的总体介绍
From fd6988496e79a6a4bdb514a4655d2920209eb85d Mon Sep 17 00:00:00 2001
From: hanle <hanle@localhost.(none)>
Date: Sat, 4 Jan 2020 23:40:27 +0800
Subject: [PATCH 0/8] *** SUBJECT HERE *** # 在此处总体介绍下你的补丁。
*** BLURB HERE *** # 在此处添加你个人对着系列补丁的一个介绍，不用介绍的太详细
Amir Goldstein (1):
locks: print unsigned ino in /proc/locks
David Abdurachmanov (1):
riscv: reject invalid syscalls below -1
Florian Fainelli (3):
ata: ahci_brcm: Fix AHCI resources management
ata: ahci_brcm: BCM7425 AHCI requires AHCI_HFLAG_DELAY_ENGINE
ata: ahci_brcm: Add missing clock management during recovery
Linus Torvalds (1):
Linux 5.5-rc4
Luc Van Oostenryck (1):
riscv: fix compile failure with EXPORT_SYMBOL() & !MMU
Olof Johansson (1):
riscv: export flush_icache_all to modules
--
2.24.1
git am打补丁的技巧
git打补丁的方式包括两种：
git am 和 git apply，两者之间有什么区别呢？两者之间的区别在于commit信息，前者只要打补丁成功，必定包括自带的commit的信息，当然你可以-s 加上你本人的singed off信息。
而后者相当于修改了文件，并且执行了git add -u *之类的指令，但是不会生成commit信息，这个信息需要你本人自己添加，也就是说，该补丁最后生成的commit信息是你自己需要
构造的。
下面具体介绍这两种指令
git apply:
git apply xxx.patch # 打上patch
git apply --stat xxx.patch # 查看patch的情况 git apply --check xxx.patch # 检查patch是否能够打上，如果没有任何输出，则说明无冲突，可以打上
git am:
git am xxx.patch # 将名字为0001-limit-log-function.patch的patch打上 git am --signoff xxx.patch # 添加-s或者--signoff，还可以把自己的名字添加为signed off by信息，作用是注明打patch的人是谁 git am *.patch # 批量打上patch，并且安装000x的序号先后打上patch,此处需要说明的每一个patch之间最好没有依赖关系，如果有依赖关系，可以修改000x序号，
# 把需要被依赖的patch先打上。
git am --abort # git patch过程中如果遇到的冲突怎么办,可以通过加上--abort指令撤回打的patch。
以上两种打patch的方式，可以根据需要操作，下面以git am为例，打补丁的过程中出现冲突该怎么处理。
git am打补丁解决冲突的方法
在打补丁的过程中，遇到冲突是不可避免的，尤其是patch来源于不一致的内核版本。
如果出现冲突，相放弃打patch，直接git am --abort即可，当然一遇到冲突就放弃打patch，实在有点说不过去。
如果在执行git am xxx.patch的时候，出现冲突，会自动在冲突文件所在的目录生成一个xxx.rej文件，里面介绍了冲突具体位置，需要按照xxx.rej的方式手动修改冲突内容。
对于冲突较多的情况，这种手工的方式确实费时费力，但是有些情况下确实没更好的办法，若想打patch成功的话，只能这么做了。
- 1、git am冲突后，可以先执行git apply --reject将不冲突的代码打入文件中。
- 2、按照xxx.rej的指示，手动修改冲突文件内容，修改完成后，删除xxx.rej文件。
- 3、执行git add .指令，将修改后的文件add进去。
- 4、执行git am --resolved即可将有冲突的补丁打成功，若此过程还是失败，再次执行2~4步骤即可。