Answers:
将补丁添加到Linux内核和其他一些项目中是必须进行签名的，但是大多数项目实际上并未使用它。
它是在SCO诉讼（以及SCO 对版权侵权的其他指控，其中大部分从未真正提起诉讼）之后引入的，作为开发者原产地证书。用来表示您证明自己已经创建了有问题的补丁程序，或者已尽其所能证明它是在适当的开源许可证下创建的，或者由某人提供给您的。否则根据这些条款。这可以帮助建立一个对相关代码的版权状态负责的人员链，以确保确保未在适当的自由软件（开放源代码）许可下未发布的受版权保护的代码不包含在内核中。
注销是提交消息末尾的一行，用于证明谁是提交的作者。其主要目的是改善对谁做了什么的跟踪，尤其是使用补丁程序。
提交示例：
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
authorgit commit 的字段不是多余的吗？我一直以为这就是为什么有一个独立的author和committer场。作者是补丁作者，提交者是应用并推送补丁的人。
git的2.7.1（2016年2月），明确了在提交b2c150d通过（2016年1月5日），大卫·惠勒（david-a-wheeler）。
（通过合并JUNIOÇ滨野- gitster-在提交7aae9ba，2016年2月5日）
git commit手册页现在包括：
-s::
--signoff::
Signed-off-by在提交日志消息的末尾，由提交者添加一行。
签名的含义取决于项目，但通常会证明提交者有权按照相同的许可证提交此作品，并同意开发者原产地证书（有关更多信息，请参见https://developercertificate.org）。
展开说明文件
--signoff修改各种文档（手册页）文件以更详细地说明什么
--signoff含义。这是受到“ lwn文章“ Bottomley：对DCO的适度提议” ”（开发者原产地证书）的启发，其中paulj指出：
我有DCO的问题是，有添加“
-s”参数git的承诺并不真正意味着你甚至听到了DCO的（该git commit手册页只字不提DCO的任何地方），别提真正见过它。那么，“
signed-off-by” 的存在如何以任何方式暗示发送者同意并承诺DCO？结合事实，我看到了对没有SOB的补丁列表的答复，这些答复只不过是“重新发送，signed-off-by以便我可以提交”。扩展git的文档将使争论更容易，使开发人员理解
--signoff使用它们时的理解。
请注意，该签核现在也适用（对于Git 2.15.x / 2.16,2018年第一季度）git pull。
参见W.Trevor King（wking）提交3a4d2c7（2017年10月12日）。
（通过合并JUNIOÇ滨野- gitster-在提交fb4cd88，2017年11月6日）
pull：传递--signoff/--no-signoff给“git merge”可以合并
--signoff，但是没有下拉传递--signoff，使用起来很不方便；允许'pull'接受选项并通过。
这个问题有一些不错的答案。我将尝试添加一个更广泛的答案，即有关当前实践中这些行/标题/尾迹的含义。特别是关于签署标头的不是很多（不是唯一的）。
当前，在诸如Git和Linux之类的项目中，诸如“ sign-off”（↑2）之类的标头或结尾（↑1）有效地构造了用于提交的元数据。这些都被附加到提交消息的末尾，即消息正文的“自由格式”（非结构化）部分之后。这些是令牌-值（或键-值）对，通常用冒号和空格（:␣）分隔。
就像我提到的那样，“签字”并不是当前实践中的唯一预告片。例如，查看此commit，它与“ Dirty Cow”有关：
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]：似乎有时也称为“ sob”（缩写）。
Signed-off-by:Linux内核项目（以及Git项目本身）分配给提交消息行的含义。但是，对于其他项目，除非项目为它们分配含义（例如，通过在项目文档中对其进行描述；例如Linux的SubmittingPatches或Git的SubmittingPatches），否则这些行是没有意义的。