Git中的Sign Off功能有什么意义？
git commit --signoff
我什么时候应该使用它，如果有的话？
#1楼
签名是提交消息末尾的一行，用于证明谁是提交的作者。 其主要目的是改善对谁做了什么的追踪，尤其是补丁。
提交示例：
Add tests to statement printer.
Signed-off-by: Super Developer <[email protected]>
如果用于开源项目，它应包含用户真实姓名。
如果分支维护者需要稍微修改补丁以便合并它们，他可以要求提交者重新启动，但这会适得其反。 他可以调整代码并在最后签名，以便作者仍然可以获得补丁，而不是引入的错误。
Add tests to statement printer.
Signed-off-by: Super Developer <[email protected]>
[[email protected]: Renamed test methods according to naming convention.]
Signed-off-by: Uber Developer <[email protected]>
资料来源： http ： //gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
#2楼
签名是将补丁纳入Linux内核和其他一些项目的要求，但大多数项目实际上并没有使用它。
它是在SCO诉讼之后引入的（以及其他指控SCO侵犯版权的指控 ，其中大部分都是他们从未真正上过庭），作为开发者原产地证书 。 它用于表示您证明您已经创建了相关的补丁，或者您根据自己的知识证明了它，它是在适当的开源许可下创建的，或者是由某人提供给您的除此之外的其他条款。 这有助于建立一系列负责相关代码版权状态的人员，以帮助确保未在适当的免费软件（开源）许可下发布的受版权保护的代码不包含在内核中。
#3楼
git 2。1。1 （2016年2月）澄清了由David A. Wheeler（ david-a-wheeler ） 提交的b2c150d （2016年1月5日） 。
（由Junio C gitster合并- gitster - in commit 7aae9ba ，2016年2月5日）
git commit man page现在包括：
-s::
--signoff::
在提交日志消息的末尾由提交者添加逐行
Signed-off-by。
签收的含义取决于项目，但它通常证明提交者有权在同一许可下提交此工作并同意开发人员原产地证书 （有关更多信息，请参阅https://developercertificate.org ）。
展开描述
--signoff文档修改各种文档（手册页）文件以更详细地解释
--signoff含义。这得益于“ 失败的文章'Bottomley：关于DCO的一个温和的提议' ”（开发者证书原产地），paulj指出：
我与DCO的问题是，在git commit中添加“
-s”参数并不意味着你甚至没有听说过DCO （git commitman page在任何地方都没有提到DCO ），没关系实际见过它。那么“
signed-off-by”的存在如何暗示发件人同意并承诺DCO？ 结合事实我已经看到列表上的回复没有SOB的补丁，只是说“使用signed-off-by重新发送signed-off-by所以我可以提交它”。扩展git的文档可以更容易地说明开发人员理解
--signoff当他们使用它时--signoff。
请注意，此签收现在（对于Git 2.15.x / 2.16，2018年第一季度）也可用于git pull 。
见W. Trevor King（ wking ）的 提交3a4d2c7 （2017年10月12日） 。
（由Junio C gitster合并- gitster -在提交fb4cd88 ，2017年11月6日）
pull：pass--signoff/--no-signoffto“git merge”合并可以采取
--signoff，但没有拉动 ---signoff，使用起来不方便; 允许'pull'采取选项并通过它。
#4楼
这个问题有一些很好的答案。 我将尝试添加更广泛的答案，即关于当前实践中这些类型的行/标题/预告片的内容。 特别是签字标题（不是唯一的标题）。
在Git和Linux等项目的当前实践中，像“签字”（↑2）这样的标题或预告片 （↑1）是提交的有效结构化元数据。 这些都附加到提交消息的末尾，在消息正文的“自由格式”（非结构化）部分之后。 这些是令牌值 （或键值 ）对，通常由冒号和空格（ :␣ ）分隔。
就像我提到的那样，“签字”并不是当前实践中唯一的预告片。 例如，参见此提交 ，它与“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 <[email protected]>
Acked-by: Hugh Dickins <[email protected]>
Reviewed-by: Michal Hocko <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Willy Tarreau <[email protected]>
Cc: Nick Piggin <[email protected]>
Cc: Greg Thelen <[email protected]>
Cc: [email protected]
Signed-off-by: Linus Torvalds <[email protected]>
除了上面的“签收”预告片外，还有：
- “抄送”（已通知补丁）
- “Acked-by”（代码所有者承认，“看起来对我很好”）
- “评论”（已审核）
- “报告和测试”（报告并测试了问题（我假设））
其他项目，例如Gerrit，有自己的标题和相关的含义。
请参阅： https ： //git.wiki.kernel.org/index.php/CommitMessageConventions
故事的道德启示
我的印象是，虽然这个特定元数据的最初动机是一些法律问题（从其他答案判断），但这种元数据的实践已经超越了处理形成一系列作者链的情况。
[↑1]： man git-interpret-trailers
[↑2]：似乎有时候这些也被称为“呜咽”（缩写）。
