签名是将补丁引入Linux内核和其他一些项目的要求，但大多数项目实际上并没有使用它。

它是在SCO诉讼（和上海合作组织其他侵犯版权的指控，其中大部分他们从未真正将其告上法庭）之后引入的，作为开发商非优惠原产地证书。它用来表示您证明您已经创建了有问题的补丁，或者您证明据您所知，它是在适当的开源许可下创建的，或者它是由其他人根据这些条款提供给您的。这有助于建立一个对相关代码的版权状态负责的人链，以帮助确保内核中不包含未在适当的自由软件（开源）许可下发布的受版权保护的代码。

Sign-off是提交消息末尾的一行，用于证明谁是提交的作者。 它的主要目的是改善跟踪谁做了什么，特别是补丁。

提交示例：

Add tests for the payment processor.


Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>

如果用于开源项目，它应该包含用户真实姓名。

如果分支维护者需要稍微修改补丁以合并它们，他可以要求提交者重新调整，但这会适得其反。 他可以调整代码并将他的签名放在最后，这样原始作者仍然可以获得补丁的荣誉。

Add tests for the payment processor.


Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>


[Project Maintainer: Renamed test methods according to naming convention.]
Signed-off-by: Project Maintainer <project.maintainer@example.com>

图片来源：http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html

TLDR；通常证明提交者有权在同一许可下提交此作品，并同意开发商非优惠原产地证书（有关更多信息，请参阅http://developercertificate.org/）。

Git 2.7.1（2016年2月）在提交b2c150d（2016年1月5日）中通过David A. Wheeler（david-a-wheeler）澄清了这一点。
^{（由Junio C Hamano----gitster--合并于提交7aae9ba,05 Feb 2016）}

git commit手册页现在包括：

-s::
--signoff::

提交者在提交日志消息的末尾添加Signed-off-by行。
签核的含义取决于项目，但它通常证明提交者有权在同一许可下提交此作品，并同意开发者非优惠原产地证书（有关更多信息，请参阅https://developercertificate.org）。

展开留档描述--signoff

修改各种文档（手册页）文件以更详细地解释--signoff的含义。

这是受“上一篇：Bottomley：关于DCO的适度提议”（开发商非优惠原产地证书）的启发，其中paulj指出：

我对DCO的问题是有在git提交中添加“-s”参数并不意味着你甚至听说过DCO（git commit手册页在任何地方都没有提到DCO），更不用说实际看到它了。

那么，“signed-off-by”的存在如何以任何方式暗示发件人同意并承诺DCO呢？结合事实，我看到列表上对没有SOB的补丁的回复只是说“用signed-off-by重新发送这个，这样我就可以提交了”。

扩展git的留档将更容易证明开发人员在使用它时理解--signoff。

请注意，此签名现在（对于Git 2.15. x/2.16，Q1 2018）也可用于git pull。

参见提交3a4d2c7（2017年10月12日）byW. Trevor King（wking）。
^{（由Junio C Hamano----gitster--合并于提交fb4cd88,2017年11月6日）}

pull：传递--signoff/--no-signoff到"git merge"

合并可以采取--signoff，但没有拉传递--signoff，它 使用不方便；允许“pull”接受该选项并传递它 通过。

在Git 2.33（2021年第三季度）中，SubmitingPatches文档进一步（重新）说明了signoff： DCO（更喜欢开源项目的CLA）背后的意图。

参见提交f003a91、提交4523dc8（2021年7月22日）byBjarmason（avar）。
^{（由Junio C Hamano----gitster--合并于提交58705b4,2021年8月4日）}

SubmittingPatches：将签名者的讨论移到“发送”上方

^{签字人：埃瓦尔·阿恩菲约尔·比亚尔马森}

将讨论添加SOB预告片的部分移到讨论生成补丁本身的部分之上。
这是有道理的，因为我们不希望有人经历“git format-patch”^（man）的过程，只是后来才意识到他们应该使用“git commit -s”^（man）或同等物。

SubmittingPatches现在在其手册页中包括：

[[签字]]

通过添加您的Signed-off-by预告片来验证您的工作

为了更好地跟踪谁做了什么，我们要求您证明您 编写补丁或有权在同一许可下传递它 作为我们的，通过“签名”您的补丁。没有签名，我们不能 你的补丁

如果（且仅当）您证明以下D-C-O：

[[dco]]

1.1开发商非优惠原产地证书

请注意，GitHub可以强制您（自2022年6月起）将signoff添加到您的提交消息中：

管理员可以要求在基于Web的提交上签名

组织所有者和存储库管理员现在可以要求开发人员签署通过GitHub的Web界面进行的提交，例如在编辑文件或合并拉取请求时。

此外，开发人员现在更容易在Web界面中完成签名，从而减少了阻止合并的提交，并减少了解决被阻止提交的时间。

启用设置后，Web界面将通知开发人员他们的提交操作也将构成注销，如下所示。
就像在命令行上使用Git的--signoff选项一样，在Web界面中注销将自动将Signed-off-by:文本附加到提交消息中。

这个问题有一些很好的答案。我会尝试添加更多 广义的答案，即关于这些类型的行/标题/预告片 是关于当前的实践。与其说是关于中的签字标题 ”””这不是唯一的一个”。

页眉或拖车（↑1）像“签名”（↑2）是，在当前 在Git和Linux等项目中实践，有效地结构化元数据 对于提交。这些都附加到提交消息的末尾， 在消息主体的“自由形式”（非结构化）部分之后。 这些是标记值（或键值类型）对，通常由 冒号和空格（:␣）。

就像我提到的，“签名”不是当前实践中唯一的预告片。看 例如这一承诺， 这与“脏牛”有关：

 mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
This is an ancient bug that was actually attempted to be fixed once
(badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
get_user_pages() race for write access") but that was then undone due to
problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").


In the meantime, the s390 situation has long been fixed, and we can now
fix it by checking the pte_dirty() bit properly (and do it better).  The
s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
software dirty bits") which made it into v3.9.  Earlier kernels will
have to look at the page state itself.


Also, the VM has become more scalable, and what used a purely
theoretical race back then has become easier to trigger.


To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
we already did a COW" rather than play racy games with FOLL_WRITE that
is very fundamental, and then use the pte dirty flag to validate that
the FOLL_COW flag is still valid.


Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com>
Acked-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Michal Hocko <mhocko@suse.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Nick Piggin <npiggin@gmail.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

除了上面的“签名”预告片外，还有：

• “CC”（已收到有关补丁的通知）
• “Acked-by”（由代码所有者确认，“对我来说看起来不错”）
• “审阅者”（已审阅）
• “报告并测试”（报告并测试了问题（我假设））

其他项目，例如Gerrit，有自己的标头和 对他们有意义

请参阅：https://git.wiki.kernel.org/index.php/CommitMessageConventions

故事的寓意

我的印象是，尽管最初的动机是 特定元数据是一些法律问题（从另一个角度来看 答案），这种元数据的实践已经超越了 #36825；，形成作者链的情况。

[↑1]：man git-interpret-trailers
[↑2]：这些有时也被称为“s-o-b”（首字母），似乎。