Sign-off是将补丁植入Linux内核和其他一些项目的必要条件，但大多数项目实际上并不使用它。

It was introduced in the wake of the SCO lawsuit, (and other accusations of copyright infringement from SCO, most of which they never actually took to court), as a Developers Certificate of Origin. It is used to say that you certify that you have created the patch in question, or that you certify that to the best of your knowledge, it was created under an appropriate open-source license, or that it has been provided to you by someone else under those terms. This can help establish a chain of people who take responsibility for the copyright status of the code in question, to help ensure that copyrighted code not released under an appropriate free software (open source) license is not included in the kernel.

签名是提交消息末尾的一行，用来证明谁是提交的作者。 它的主要目的是改进对谁做了什么的跟踪，特别是通过补丁。

示例提交:

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月)在David A. Wheeler (David -a- Wheeler)提交的b2c150d(2016年1月05日)中澄清了这一点。 (由Junio C Hamano—gitster—在commit 7aae9ba中合并，2016年2月5日)

Git提交手册页现在包括:

-s::
--signoff::

在提交日志消息的末尾添加提交者的签到行。 签名的含义取决于项目，但它通常证明提交者有权在相同的许可下提交该作品，并同意开发者原产地证书(更多信息请参阅https://developercertificate.org)。

展开描述——signoff的文档

Modify various document (man page) files to explain in more detail what --signoff means. This was inspired by "lwn article 'Bottomley: A modest proposal on the DCO'" (Developer Certificate of Origin) where paulj noted: The issue I have with DCO is that there adding a "-s" argument to git commit doesn't really mean you have even heard of the DCO (the git commit man page makes no mention of the DCO anywhere), never mind actually seen it. So how can the presence of "signed-off-by" in any way imply the sender is agreeing to and committing to the DCO? Combined with fact I've seen replies on lists to patches without SOBs that say nothing more than "Resend this with signed-off-by so I can commit it". Extending git's documentation will make it easier to argue that developers understood --signoff when they use it.

请注意，现在(对于Git 2.15.x/2.16, 2018年第一季度)也可用于Git拉取。

参见W. Trevor King (wking)提交的commit 3a4d2c7(2017年10月12日)。 (由Junio C Hamano合并- gitster -在commit fb4cd88, 2017年11月6日)

拉:传球——signoff/——没有signoff到“git merge”

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

在Git 2.33(2021年第三季度)中，SubmitingPatches文档进一步(重新)说明了签名背后的意图:DCO(对于开源项目，首选cla)。

参见通过Ævar Arnfjörð Bjarmason (avar)提交f003a91，提交4523dc8(2021年7月22日)。 (由Junio C Hamano—gitster—在提交58705b4中合并，2021年8月4日)

提交补丁:移动讨论签名以上的“发送” 署名:Ævar Arnfjörð Bjarmason

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

subtingpatches现在包含在它的手册页中:

[[签署]] 通过添加你的签收预告片来证明你的工作 为了更好地追踪谁做了什么，我们要求您证明您 编写补丁或有权在同一许可证下传递它 就像我们的一样，签下你的补丁。没有签名，我们就不能 接受你的补丁。 如果(仅当)您证明以下D-C-O: [[dco]] .发展商原产地证书

请注意，GitHub可以强制你(从2022年6月开始)在你的提交消息中添加签收:

Admins can require sign off on web-based commits Organization owners and repository admins can now require developers to sign off on commits made through GitHub's web interface, such as when editing a file or merging a pull request. Also, it is now easier for developers to complete a signoff in the web interface, resulting in fewer commits being blocked from merging and less time spent resolving blocked commits. When the setting is enabled, the web interface will inform developers that their action of committing will also constitute signing off, as shown below. Like using Git's --signoff option on the command line, signing off in the web interface will automatically append the Signed-off-by: text to the commit message.

关于这个问题，有一些很好的答案。我会试着再加一个 宽泛的回答，即关于这些行/头/片尾 在目前的实践中。不是关于结束的头球 特别的(这不是唯一的)。

当前是头或尾(↑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

故事的寓意

这是我的印象，虽然最初的动机 特定的元数据是一些法律问题(通过其他判断) 答案)，这种元数据的实践已经超越了仅仅 处理形成著作权链的案件。

[↑1]:man git-interpret-trailers [↑2]:它们有时似乎也被称为“s-o-b”(首字母)。