创建拉取请求
本章描述了维护者如何创建并提交拉取请求给其他维护者。这对于将一个维护者的更改传输到另一个维护者的树中非常有用。
这份文档是由Tobin C. Harding（当时并不是一位经验丰富的维护者）根据Greg Kroah-Hartman和Linus Torvalds在LKML上的评论撰写的。Jonathan Corbet和Mauro Carvalho Chehab提出了建议和修正。误导是无意的但不可避免，请将滥用行为指向Tobin C. Harding me@tobin.cc。
原始电子邮件线程：
https://lore.kernel.org/r/20171114110500.GA21175@kroah.com
创建分支
首先，您需要在一个单独的分支上拥有您希望包含在拉取请求中的所有更改。通常，您会将此分支基于您打算发送拉取请求的开发者树中的一个分支。
为了创建拉取请求，您必须首先给刚刚创建的分支打上标签。建议您选择一个有意义的标签名称，以便您和其他人即使过了一段时间仍能理解。一个好的做法是在名称中包含原始子系统的指示器和目标内核版本。
Greg提供了以下建议。一个混杂的驱动程序/char的拉取请求，将应用于内核版本4.15-rc1，可以命名为char-misc-4.15-rc1。如果这样的标签是从名为char-misc-next的分支产生的，您将使用以下命令：
git tag -s char-misc-4.15-rc1 char-misc-next
这将基于char-misc-next分支中的最后一次提交创建一个名为char-misc-4.15-rc1的签名标签，并使用您的gpg密钥对其进行签名（请参阅配置Git）。
Linus只会接受基于签名标签的拉取请求。其他维护者可能会有所不同。
当您运行上述命令时，git会将您带入编辑器，并要求您描述该标签。在这种情况下，您正在描述一个拉取请求，因此要概述其中包含了什么，为什么应该合并，以及是否进行了任何测试。所有这些信息最终都会出现在标签本身中，然后在维护者合并拉取请求时出现在合并提交中。因此，请写得好，因为它将永远存在于内核树中。
正如Linus所说：
无论如何，对我来说，重要的部分是消息。我想要理解我正在拉取的内容，以及为什么我应该拉取它。我还希望将该消息用作合并的消息，因此它不仅对我有意义，而且作为历史记录也有意义。
请注意，如果拉取请求有什么奇怪之处，那么解释中应该非常清楚。如果您正在触及您不维护的文件，请解释为什么。无论如何，我都会在diffstat中看到它，如果您没有提到它，我会变得更加怀疑。当您在合并窗口之后向我发送新的内容（甚至是修复bug的内容，但看起来很可怕的内容），请不仅解释它们做了什么以及为什么要这样做，还要解释时机。是什么导致这个内容没有通过合并窗口。。
我会同时考虑您在电子邮件拉取请求中写的内容和在签名标签中写的内容，因此根据您的工作流程，您可以在签名标签中描述您的工作（这也将自动转换为拉取请求电子邮件），或者您可以在签名标签中只放置一个没有趣味的占位符，并在您实际发送拉取请求时稍后描述工作。
是的，我会编辑消息。部分原因是因为我倾向于做一些微不足道的格式化（整个缩进和引用等），但部分原因是因为消息的一部分可能在我拉取时对我有意义（描述冲突和您发送它的个人问题），但在合并提交消息的上下文中可能没有意义，因此我会尽量使其有意义。我还会纠正我注意到的任何拼写错误和语法错误，特别是对于非母语者（但也适用于母语者;^)。但我可能会漏掉一些，甚至添加一些。
Linus
Greg给出了一个示例拉取请求：
Char/Misc patches for 4.15-rc1
Here is the big char/misc patch set for the 4.15-rc1 merge window.
Contained in here is the normal set of new functions added to all
of these crazy drivers, as well as the following brand new
subsystems:
- time_travel_controller: Finally a set of drivers for the
latest time travel bus architecture that provides i/o to
the CPU before it asked for it, allowing uninterrupted
processing
- relativity_shifters: due to the affect that the
time_travel_controllers have on the overall system, there
was a need for a new set of relativity shifter drivers to
accommodate the newly formed black holes that would
threaten to suck CPUs into them. This subsystem handles
this in a way to successfully neutralize the problems.
There is a Kconfig option to force these to be enabled
when needed, so problems should not occur.
All of these patches have been successfully tested in the latest
linux-next releases, and the original problems that it found have
all been resolved (apologies to anyone living near Canberra for the
lack of the Kconfig options in the earlier versions of the
linux-next tree creations.)
Signed-off-by: Your-name-here <your_email@domain>
标签消息格式就像一个git提交ID。顶部一行是“摘要主题”，并确保在底部签名。
现在您有了一个本地签名标签，您需要将其推送到可以检索的位置：
git push origin char-misc-4.15-rc1
创建拉取请求
最后要做的事情是创建拉取请求消息。git会很方便地使用git request-pull命令为您执行此操作，但它需要一些帮助来确定您想要拉取什么，以及要基于哪个位置进行拉取（以显示要拉取的正确更改和diffstat）。以下命令将生成一个拉取请求：
git request-pull master git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ char-misc-4.15-rc1
引用Greg的话：
这是要求git比较从'char-misc-4.15-rc1'标签位置到'master'分支的头部的差异（在我的情况下，指向我从Linus的树中分叉出来的最后位置，通常是一个-rc发布），并使用git://协议进行拉取。如果您希望使用https://，也可以在这里使用（但请注意，一些身处防火墙后面的人可能会在使用https git拉取时遇到问题）。
如果要求拉取的char-misc-4.15-rc1标签在我要求拉取的存储库中不存在，git会抱怨说它不存在，这是一个记住实际将其推送到公共位置的方便方法。
'git request-pull'的输出将包含要从中拉取的git树和特定标签的位置，以及该标签的完整文本描述（这就是为什么您需要在该标签中提供良好的信息）。它还将创建一个拉取请求的diffstat和一个提供拉取请求的各个提交的shortlog。
Linus回应说他倾向于更喜欢git://协议。其他维护者可能有不同的偏好。另外，请注意，如果您在没有签名标签的情况下创建拉取请求，则https://可能是一个更好的选择。请参阅原始线程以获取完整讨论。
提交拉取请求
拉取请求的提交方式与普通补丁相同。以内联电子邮件的形式发送给维护者，并抄送LKML和任何必要的子系统特定列表。发送给Linus的拉取请求通常具有以下主题行：
[GIT PULL]