答案 0 :(得分：475)
签名是将补丁纳入Linux内核和其他一些项目的要求，但大多数项目实际上并没有使用它。
它是在SCO lawsuit，（和other accusations of copyright infringement from SCO之后引入的，其中大部分都是他们从未真正上过庭院的）Developers Certificate of Origin。它用于表示您证明您已经创建了相关的补丁，或者您根据自己的知识证明了它，它是在适当的开源许可下创建的，或者是由某人提供给您的除此之外的其他条款。这有助于建立一系列负责相关代码版权状态的人员，以帮助确保未在适当的免费软件（开源）许可下发布的受版权保护的代码不包含在内核中。
答案 1 :(得分：62)
签名是提交消息末尾的一行，用于证明谁是提交的作者。 其主要目的是改善对谁做了什么的跟踪，尤其是补丁。
提交示例：
Add tests to statement printer.
Signed-off-by: Super Developer <super.dev@gmail.com>
如果用于开源项目，它应该包含用户真实姓名。
如果分支维护者需要稍微修改补丁以便合并它们，他可以要求提交者重新启动，但这会适得其反。 他可以调整代码并在结尾处进行签名，这样作者仍然可以获得补丁，而不是引入的错误。
Add tests to statement printer.
Signed-off-by: Super Developer <super.dev@gmail.com>
[uber.dev@gmail.com: Renamed test methods according to naming convention.]
Signed-off-by: Uber Developer <uber.dev@gmail.com>
来源：http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
答案 2 :(得分：28)
git 2.7.1（2016年2月）在commit b2c150d（2016年1月5日）David A. Wheeler (david-a-wheeler)中阐明了这一点。
（由Junio C Hamano -- gitster --合并于commit 7aae9ba，2016年2月5日）
git commit man page现在包括：
-s::
--signoff::
在提交日志消息末尾的提交者处添加
Signed-off-by行 签收的含义取决于项目，但通常证明提交者有权在同一许可下提交此作品并同意开发人员原产地证书（请参阅https://developercertificate.org更多信息）。
展开描述
的文档--signoff修改各种文档（手册页）文件，以更详细地解释
--signoff的含义。这是受到“lwn article 'Bottomley: A modest proposal on the DCO'”（开发者证书原产地）的启发，paulj指出：
我与DCO的问题是向git commit添加“
-s”参数并不意味着你甚至没有听说过DCO （ { {1}}手册页未提及任何地方的DCO ），更别提实际看到它了。那么“
git commit”的存在如何暗示发件人同意并承诺DCO？结合事实我已经在列表上看到了对没有SOB的补丁的回复，这些回复仅仅是“用signed-off-by重新发送这个，所以我可以提交它”。扩展git的文档可以更容易地说明开发人员在使用它时理解
signed-off-by。
请注意，此签收现在（对于Git 2.15.x / 2.16，2018年第一季度）也适用于--signoff。
commit 3a4d2c7见W. Trevor King (wking)（2017年10月12日）
（Junio C Hamano -- gitster --合并于commit fb4cd88，2017年11月6日）
git pull：将pull传递给“--signoff/--no-signoff”合并可以
git merge，但不会将--signoff拉下来 不方便使用;允许'--signoff'选择并传递它 通过
答案 3 :(得分：14)
这个问题有一些很好的答案。我会尝试添加更多 广泛的答案，即关于这些种类的行/标题/预告片 在目前的实践中。与其说是签名标题 特别是（它不是唯一的一个）。
标题或预告片（↑1），如“签收”（↑2），目前
在Git和Linux等项目中实践，有效的结构化元数据
提交。这些都附加到提交消息的末尾，
之后的“自由形式”（非结构化）部分消息的正文。
这些是令牌值（或键值）对，通常由a分隔
冒号和空格（:␣）。
就像我提到的那样，“签字”并不是当前实践中唯一的预告片。看到 例如this commit， 这与“肮脏的牛”有关：
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>
除了上面的“签收”预告片外，还有：
其他项目，例如Gerrit，有自己的标题和 他们的相关意义。
请参阅：https://git.wiki.kernel.org/index.php/CommitMessageConventions
这是我的印象，虽然这是最初的动机 特定元数据是一些法律问题（另一方面判断） 答案），这种元数据的实践已经超越了公正 处理形成作者链的案例。
[↑1]：man git-interpret-trailers
[↑2]：这些有时也被称为“s-o-b”（缩写），似乎。