Git 中的 Sign Off 功能有什么用？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1962094/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the Sign Off feature in Git for?
提问by Clark Gaebel
What's the point of the Sign Off feature in Git?
Git中的Sign Off 功能有什么意义？
git commit --signoff
When should I use it, if at all?
我应该什么时候使用它，如果有的话？
采纳答案by Brian Campbell
Sign-off is a requirement for getting patches into the Linux kernel and a few other projects, but most projects don't actually use it.
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.
它是在SCO 诉讼（以及SCO 的其他侵犯版权指控，其中大部分从未真正告上法庭）之后引入的，作为开发者原产地证书。它用于表示您证明您已经创建了有问题的补丁，或者您证明据您所知，它是在适当的开源许可下创建的，或者它是由某人提供给您的否则根据这些条款。这可以帮助建立一个对相关代码的版权状态负责的人员链，以帮助确保未在适当的自由软件（开源）许可下发布的受版权保护的代码不包含在内核中。
回答by Andrzej Rehmann
Sign-off is a line at the end of the commit message which certifies who is the author of the commit. Its main purpose is to improve tracking of who did what, especially with patches.
Sign-off 是提交消息末尾的一行，用于证明谁是提交的作者。它的主要目的是改进对谁做了什么的跟踪，尤其是补丁。
Example commit:
示例提交：
Add tests for the payment processor.
Signed-off-by: Humpty Dumpty <[email protected]>
It should contain the user real name if used for an open-source project.
如果用于开源项目，它应该包含用户真实姓名。
If branch maintainer need to slightly modify patches in order to merge them, he could ask the submitter to rediff, but it would be counter-productive. He can adjust the code and put his sign-off at the end so the original author still gets credit for the patch.
如果分支维护者需要稍微修改补丁以合并它们，他可以要求提交者重新比较，但这会适得其反。他可以调整代码并将他的签名放在最后，这样原始作者仍然可以得到补丁的信任。
Add tests for the payment processor.
Signed-off-by: Humpty Dumpty <[email protected]>
[Project Maintainer: Renamed test methods according to naming convention.]
Signed-off-by: Project Maintainer <[email protected]>
Source: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
来源：http: //gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
回答by VonC
git 2.7.1 (February 2016) clarifies that in commit b2c150d(05 Jan 2016) by David A. Wheeler (david-a-wheeler).
(Merged by Junio C Hamano -- gitster--in commit 7aae9ba, 05 Feb 2016)
git 2.7.1（2016 年 2 月）在David A. Wheeler ( ) 的提交 b2c150d（2016 年 1 月 5日）中阐明了这一点。（由Junio C Hamano合并-- --在commit 7aae9ba，2016 年 2 月 5 日）david-a-wheelergitster
git commitman pagenow includes:
git commit手册页现在包括：
-s::
--signoff::
Add
Signed-off-byline by the committer at the end of the commit log message.
The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin(see https://developercertificate.orgfor more information).
Signed-off-by在提交日志消息的末尾添加提交者的行。
签核的含义取决于项目，但它通常证明提交者有权在同一许可证下提交此作品，并同意开发者原产地证书（有关更多信息，请参阅https://developercertificate.org）。
Expand documentation describing
--signoffModify various document (man page) files to explain in more detail what
--signoffmeans.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(thegit commitman 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 withsigned-off-byso I can commit it".Extending git's documentation will make it easier to argue that developers understood
--signoffwhen they use it.
展开说明文档
--signoff修改各种文档（手册页）文件以更详细地解释其
--signoff含义。这是受到“ lwn 文章‘Bottomley：关于 DCO 的适度提案’”（开发商原产地证书）的启发，其中 paulj 指出：
我有DCO的问题是，有添加“
-s”参数git的承诺并不真正意味着你甚至听到了DCO的（该git commit手册页只字不提DCO的任何地方），别提真正见过它。那么，“
signed-off-by”的存在如何以任何方式暗示发件人同意并承诺遵守 DCO？结合事实，我在列表上看到了对没有 SOB 的补丁的回复，这些回复仅说“重新发送，signed-off-by以便我可以提交”。扩展 git 的文档将更容易证明开发人员
--signoff在使用它时理解它。
Note that this signoff is now (for Git 2.15.x/2.16, Q1 2018) available for git pullas well.
请注意，此签收现在（对于 Git 2.15.x/2.16，2018 年第一季度）也可用git pull。
See commit 3a4d2c7(12 Oct 2017) by W. Trevor King (wking).
(Merged by Junio C Hamano -- gitster--in commit fb4cd88, 06 Nov 2017)
请参阅W. Trevor King ( ) 的commit 3a4d2c7（2017 年 10 月 12 日）。（由Junio C Hamano合并-- --在提交 fb4cd88 中，2017 年 11 月 6 日）wkinggitster
pull: pass--signoff/--no-signoffto "git merge"merge can take
--signoff, but without pull passing--signoffdown, it is inconvenient to use; allow 'pull' to take the option and pass it through.
pull: 传递--signoff/--no-signoff给 "git merge"merge 可以取
--signoff，但是没有 pull 传--signoff下来，使用起来不方便；允许 'pull' 选择并通过它。
回答by Guildenstern
There are some nice answers on this question. I'll try to add a more broad answer, namely about what these kinds of lines/headers/trailers are about in current practice. Not so much about the sign-off header in particular (it's not the only one).
关于这个问题有一些很好的答案。我将尝试添加一个更广泛的答案，即关于这些类型的行/标题/预告片在当前实践中的含义。特别是关于签署头的不是那么多（它不是唯一的）。
Headersor trailers(↑1) like “sign-off” (↑2) is, in current
practice in projects like Git and Linux, effectively structured metadata
for the commit. These are all appended to the end of the commit message,
after the “free form” (unstructured) part of the body of the message.
These are token–value(or key–value) pairs typically delimited by a
colon and a space (:?).
在当前的 Git 和 Linux 等项目实践中，像“签署”（↑2）这样的标题或预告片（↑1）是提交的有效结构化元数据。这些都附加到提交消息的末尾，在消息正文的“自由形式”（非结构化）部分之后。这些是通常由冒号和空格 ( )分隔的标记-值（或键-值）对:?。
Like I mentioned, “sign-off” is not the only trailer in current practice. See for example this commit, which has to do with “Dirty Cow”:
就像我提到的，“签字”并不是当前实践中唯一的预告片。例如，参见这个 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 <[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]>
In addition to the “sign-off” trailer in the above, there is:
除了上面的“签到”预告片，还有：
- “Cc” (was notified about the patch)
- “Acked-by” (acknowledged by the owner of the code, “looks good to me”)
- “Reviewed-by” (reviewed)
- “Reported-and-tested-by” (reported and tested the issue (I assume))
- “抄送”（已通知补丁）
- “Acked-by”（被代码所有者认可，“对我来说看起来不错”）
- “审核人”（已审核）
- “Reported-and-tested-by”（报告并测试了问题（我假设））
Other projects, like for example Gerrit, have their own headers and associated meaning for them.
其他项目，例如 Gerrit，有自己的标题和相关的含义。
See: https://git.wiki.kernel.org/index.php/CommitMessageConventions
请参阅：https: //git.wiki.kernel.org/index.php/CommitMessageConventions
Moral of the story
故事的道德启示
It is my impression that, although the initial motivation for this particular metadata was some legal issues (judging by the other answers), the practice of such metadata has progressed beyond just dealing with the case of forming a chain of authorship.
我的印象是，虽然这个特定元数据的最初动机是一些法律问题（从其他答案来看），但这种元数据的实践已经不仅仅是处理形成作者身份链的情况。
[↑1]: man git-interpret-trailers
[↑2]: These are also sometimes called “s-o-b” (initials), it seems.
[↑1]：man git-interpret-trailers
[↑2]：这些似乎有时也被称为“sob”（首字母缩写）。
