Git中的Sign Off功能是什么？

Question

Git中的Sign Off功能是什么？

git commit --signoff

Run Code Online (Sandbox Code Playgroud)

我什么时候应该使用它,如果有的话？

Answer 1

Bri*_*ell 499

签名是将补丁纳入Linux内核和其他一些项目的要求,但大多数项目实际上并没有使用它.

它是在SCO诉讼之后引入的(以及其他指控SCO侵犯版权的指控,其中大部分都是他们从未真正上过庭),作为开发者原产地证书.它用于表示您证明您已经创建了相关的补丁,或者您根据自己的知识证明了它,它是在适当的开源许可下创建的,或者是由某人提供给您的除此之外的其他条款.这有助于建立一系列负责相关代码版权状态的人员,以帮助确保未在适当的免费软件(开源)许可下发布的受版权保护的代码不包含在内核中.

应该注意的是,所描述的含义是由Linux内核项目(以及Git项目本身)分配给`Signed-off-by:`提交消息行的含义.但是,对于其他项目,除非项目为其赋予意义,否则这些行是没有意义的(例如,通过在项目文档中描述它们;例如Linux的[SubmittingPatches](http://git.kernel.org/?p=linux/kernel/ git/torvalds/linux-2.6.git; a = blob; f = Documentation/SubmittingPatches; hb = HEAD)或Git的[SubmittingPatches](http://git.kernel.org/?p=git/git.git;a =斑点; F =文档/ SubmittingPatches; HB = HEAD)). (83认同)
如果没有PGP密钥,如何确定签收是真的？ (62认同)
那么为什么需要在提交消息中完成呢？我认为提交有一个作者附加到他们,他们是SHA1哈希的一部分？ (36认同)
@Leif仅仅是作者身份信息是不够的.我可能已经编写了一个补丁,但如果我基于Unix的一些代码,我就没有权限在GPL下发布它(至少没有从更高级别的人那里签字).或者,补丁可以在几个不同的维护者之间进行,然后在内核树中清理; 签收表明了监管链.阅读我链接的原产地证书; 这就是添加签收行时的含义."作者"标题可能不准确,并不一定意味着与原产地证书中的所有内容达成一致. (31认同)
@HRJ签约的真实性实际上在你身上(提交者).不是在作者身上,也不是在签名后自己.如果以后有人(主要是已签约)对其无效提出异议,您最好随身携带一封电子邮件或证明他同意的电子邮件.提交者可能会说他没有提交这样的blob如果blob不是GPG签名(恕我直言,弱防守,但......).在这种情况下,提交者可以使用-S来关闭圆圈.现在使用-S和-s,您可以根据提交者的说法拥有一系列监管权,即某些作者编写的代码有权被某些已签署的高级用户使用. (6认同)
就个人而言,我永远不会*从其他人那里申请补丁**没有提交提交元数据.这是应用补丁的旧SVN方式.git中的理想补丁是从某处提交的.提交的提交者可能是我,但*作者*将是他们.这提供了与签字有效的信息.如果他们发现它不是他们拥有的代码,你就知道要与*作者*交谈. (4认同)
@void.pointer 作者身份是不够的。如果我在一家公司工作，并且我编写了一个补丁，则该补丁的版权属于该公司。未经适当的管理层批准，我无权根据 GPL 条款发布该补丁。因此，如果我编写一个补丁并将其发送到 LKML，作者信息将是正确的，但没有人真正证明在 GPL 下分发该补丁实际上有法律依据。事实上，可以剥离这些信息并没有什么区别。 (3认同)
@Frizlab我还是不买.在那里拥有相同的信息两次并不能有效地传达您授予发布补丁的权限.你首先将*交给某人*的事实给予了许可.另外,谁说某人不进去,只是编辑提交消息,在那里为你添加？它仍然是OSS社区强制执行的愚蠢手势. (3认同)
@BrianCampbell作者应该绰绰有余,我还是不明白.通过`am`(通过`format-patch`创建)应用的补丁带有正确的作者,并且在应用补丁时应用该作者.对于从`git diff`输出应用的补丁(它没有提交元数据),签名不会有任何帮助,因为提交消息没有与udiff捆绑在一起. (2认同)
@BrianCampbell如果由公司拥有,则签名仍然是我的姓名和电子邮件(域名可能由公司注册).作为提交消息的一部分的签名并不比作者字段更安全.它仍然可以剥离.与作者字段相比,签名没有任何额外的信息.也许如果你可以解释作者没有注销的东西,那会让它感觉不那么多余. (2认同)
@ void.pointer这不是多余的，因为签署_does_传达的东西比author字段还多。签名意味着（简化）“我证明此提交中的代码可以在项目许可的条款下发布。” author字段表示“我这样做了”；它的确不是“可以”发布…换句话说，在签署时，您对此承诺承担全部责任，因为它可以合法分发。这不是安全问题。如果要保护提交，请对其进行签名。 (2认同)
@void.pointer 提交通常必须签署的签署事项。没有私钥就不能更改已签名的提交。签字后仍然添加了一些信息。不是因为你做了什么，你做了什么。您可以从任何地方复制粘贴一些代码，然后提交。如果粘贴的代码不允许使用并且有调查，那该怪谁？签署承诺的人；不是犯下这件事的人。这就是它的意思。有用吗？我不知道… (2认同)

Answer 2

And*_*ann 65

签名是提交消息末尾的一行,用于证明谁是提交的作者.其主要目的是改善对谁做了什么的追踪,尤其是补丁.

提交示例:

Add tests to statement printer.

Signed-off-by: Super Developer <super.dev@gmail.com>

Run Code Online (Sandbox Code Playgroud)

如果用于开源项目,它应包含用户真实姓名.

如果分支维护者需要稍微修改补丁以便合并它们,他可以要求提交者重新启动,但这会适得其反.他可以调整代码并在最后签名,以便作者仍然可以获得补丁,而不是引入的错误.

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>

Run Code Online (Sandbox Code Playgroud)

资料来源:http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html

git提交的`author`字段不是多余的吗？我一直认为这就是为什么有一个单独的`author`和`committer`字段.作者是补丁编写者,提交者是应用和推送补丁的人. (33认同)
它真的*证明了提交者的作者是谁吗？我的意思是,和-S( - gpg-sign)一样多,因为我不这么认为.我认为任何人都可以添加任何名称和电子邮件的"Signed-off-by"行,而GPG签名更可靠,但也许我错了. (9认同)
“签名是提交消息末尾的一行，用于证明谁是提交的作者。它的主要目的是改进对谁做了什么的跟踪，尤其是补丁。” ——这几乎肯定是错误的（特别是第一句话）。作为反例，请参见例如 [b2c150d3aa（在 VonC 的回答中链接到）](https://github.com/git/git/commit/b2c150d3aa82f6583b9aadfecc5f8fa1c74aca09)，它有两个签名的标头；一个由*作者* 提供，一个由维护者提供。这是 Git 和 Linux 项目中的常见做法。 (2认同)

Answer 3

Von*_*onC 28

git 2.1.1(2016年2月)澄清了在承诺b2c150d(2016年1月5日)由David A. Wheeler(david-a-wheeler).
^{(由Junio C gitsterHamano合并- -在提交7aae9ba,2016年2月5日)}

git commit手册页现在包括:

-s::
--signoff::

Run Code Online (Sandbox Code Playgroud)

Signed-off-by在提交日志消息的末尾由提交者添加行.
签收的含义取决于项目,但它通常证明提交者有权在同一许可下提交此工作并同意开发人员原产地证书(有关更多信息,请参阅https://developercertificate.org).

展开文档描述 --signoff

修改各种文档(手册页)文件以更详细地解释什么--signoff意思.

这得益于" 失败的文章'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()提交3a4d2c7(2017年10月12日).^(由^{Junio C}^Hamano^合并^-^-^在^{提交fb4cd88}^{,2017年11月6日)}wking
^gitster

pull:传递--signoff/--no-signoff给" git merge"

合并可以采取--signoff,但没有拉--signoff下来,使用起来不方便; 允许' pull'采取选择并通过它.

VonC,你是一个真正的Git策展人.在这样的问题上,你总能拥有如此结构良好,信息量大且交叉引用的答案 - 将Git开发的历史追溯到最终面向用户的工具和文档.非常感谢你的帮忙. (3认同)
@Guildenstern感谢您的好评. (3认同)
即使使用git提交文档(最后)引用文档,-s标志也是为了表示知识和协议/同意/ ??? 我相信SOB在法律上非常弱.至少,我认为SOB是由Linus发明的,用于解决社会问题,其他人则主张高开销的官僚机构.Linus不想要任何东西,但想出来把它们关起来.据我所知,律师不会建议你投入太多信心(如果有的话).(我是LWN的'paulj'). (2认同)

Answer 4

Gui*_*ern 15

这个问题有一些很好的答案.我将尝试添加更广泛的答案,即关于当前实践中这些类型的行/标题/预告片的内容.特别是签字标题(不是唯一的标题).

在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 <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>

Run Code Online (Sandbox Code Playgroud)

除了上面的"签收"预告片外,还有:

"抄送"(已通知补丁)
"Acked-by"(代码所有者承认,"看起来对我很好")
"评论"(已审核)
"报告和测试"(报告并测试了问题(我假设))

其他项目,例如Gerrit,有自己的标题和相关的含义.

请参阅:https://git.wiki.kernel.org/index.php/CommitMessageConventions

故事的道德启示

我的印象是,虽然这个特定元数据的最初动机是一些法律问题(从其他答案判断),但这种元数据的实践已经超越了处理形成一系列作者链的情况.

[↑1]:man git-interpret-trailers
[↑2]:这些有时候也被称为"呜咽"(姓名首字母).

有趣的用例.+1 (2认同)

归档时间：	15 年，8 月前
查看次数：	132756 次
最近记录：	6 年，11 月前

Git中的Sign Off功能是什么？

展开文档描述 `--signoff`

`pull`:传递`--signoff/--no-signoff`给" `git merge`"

故事的道德启示

Git中的Sign Off功能是什么？

展开文档描述 --signoff

pull:传递--signoff/--no-signoff给" git merge"

故事的道德启示

展开文档描述 `--signoff`

`pull`:传递`--signoff/--no-signoff`给" `git merge`"