Git 中的 Sign Off 功能有什么用？

Question

Git 中的注销功能有什么意义< /a>?

git commit --signoff

如果需要的话，我应该什么时候使用它？

Answer 1

签核是将补丁添加到 Linux 内核和其他一些项目中的必要条件，但大多数项目实际上并不使用它。

它是在SCO 诉讼之后引入的，（以及SCO 的其他侵犯版权的指控，其中大部分从未真正告上法庭），作为 开发者原产地证书。它用于表示您证明您已经创建了相关补丁，或者您证明据您所知，它是在适当的开源许可证下创建的，或者它是由某人提供给您的其他根据这些条款。这可以帮助建立一个对相关代码的版权状态负责的人员链，以帮助确保未在适当的自由软件（开源）许可证下发布的受版权保护的代码不包含在内核中。

Answer 2

签核是提交消息末尾的一行，用于证明提交的作者是谁。
其主要目的是改进对谁做了什么的跟踪，尤其是补丁。

示例提交：

Add tests for the payment processor.

Signed-off-by: Humpty Dumpty <[email protected]>

如果用于开源项目，则应包含用户真实姓名。

如果分支维护者需要稍微修改补丁以合并它们，他可以要求提交者重新比较，但这会适得其反。
他可以调整代码并将其签名放在最后，这样原始作者仍然可以获得补丁的功劳。

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

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

Answer 3

太长了；通常证明提交者有权在同一许可证下提交此作品，并同意开发者原产地证书（请参阅http://developercertificate.org/ 了解更多信息）。

---

Git 2.7.1（2016 年 2 月）澄清了 commit b2c150d（2016 年 1 月 5 日） David A. Wheeler (david-a-wheeler)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 7aae9ba，2016 年 2 月 5 日）}

git commit 手册页 现在包括：

-s::
--signoff::

在提交日志消息末尾添加提交者的 Signed-off-by 行。
签核的含义取决于项目，但它通常证明提交者有权在同一许可证下提交此作品并同意开发者原产地证书（请参阅https://developercertificate.org 了解更多信息）。

---

展开描述--signoff的文档

修改各种文档（手册页）文件以更详细地解释 --signoff 的含义。

这受到“lwn 文章“Bottomley：关于 D​​CO 的温和建议”的启发”（开发者原产地证书），paulj 指出：

<块引用>

我对 DCO 的问题是，向 git commit 添加“-s”参数并不意味着您甚至听说过 DCO（< strong>git commit 手册页在任何地方都没有提到 DCO），更不用说实际看到它了。

<块引用>

那么，“signed-off-by”的存在如何以任何方式暗示发件人同意并承诺 DCO？结合事实，我在列表上看到了对没有 SOB 的补丁的回复，内容无非是“用 signed-off-by 重新发送此内容，以便我可以提交它”。

扩展 git 的文档将使开发人员在使用它时更容易理解 --signoff。

---

请注意，此签核现在（对于 Git 2.15.x/2.16，2018 年第一季度）也可用于 git pull。

请参阅 提交 3a4d2c7（2017 年 10 月 12 日），作者：W.特雷弗·金 (wking)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交fb4cd88，2017年11月6日）}

pull：将 --signoff/--no-signoff 传递给“git merge”

合并可以采用--signoff，但如果不拉动传递--signoff，它
使用不方便；允许“pull”接受选项并传递它
通过。

---

在 Git 2.33（2021 年第 3 季度）中，SubmitingPatches 文档进一步（重新）说明了signoff 背后的意图：DCO (对于开源项目更喜欢 CLA）。

请参阅提交f003a91，提交 4523dc8（2021 年 7 月 22 日），作者：Ævar Arnfjörð Bjarmason (<代码>avar)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 58705b4，2021 年 8 月 4 日）}

SubmittingPatches：移动有关 Signed-off 的讨论 -通过上面的“发送”

^{签字人：Ævar Arnfjörð Bjarmason}

将讨论添加 SOB 预告片的部分移至讨论生成补丁本身的部分上方。
这是有道理的，因为我们不希望有人经历“git 格式补丁"^(man)，后来才意识到他们应该使用“git commit -s"^(man) 或同等内容。

SubmittingPatches 现在包含在其 手册页< /a>:

[[签字]]

通过添加 Signed-off-by 预告片来证明您的工作

为了更好地跟踪谁做了什么，我们要求您证明您
编写补丁或有权在同一许可证下传递补丁
和我们一样，通过“签署”您的补丁。如果没有签字，我们无法
接受您的补丁。

如果（且仅当）您认证以下 DCO：

[[dco]]

.开发商原产地证书1.1

---

请注意，GitHub 可以强制您（自 2022 年 6 月起）在提交消息中添加签名：

管理员可以要求签署基于网络的提交

组织所有者和存储库管理员现在可以要求开发人员签署通过 GitHub 的 Web 界面所做的提交，例如在编辑文件或合并拉取请求时。

此外，开发人员现在可以更轻松地在 Web 界面中完成签核，从而减少被阻止合并的提交，并减少解决被阻止提交所花费的时间。

启用该设置后，Web 界面将通知开发者，他们的提交操作也将构成注销，如下所示。
与在命令行上使用 Git 的 --signoff 选项一样，在 Web 界面中注销会自动将 Signed-off-by: 文本附加到提交消息中。 p>

Answer 4

关于这个问题有一些很好的答案。我会尝试添加更多
广泛的答案，即关于这些类型的台词/标题/预告片的内容
是关于目前的实践。与中的签核标题无关
特别的（这不是唯一的）。

标题或预告片 (↑1)，如“签核”(↑2)，在当前
在 Git 和 Linux 等项目中进行实践，有效结构化元数据
用于提交。这些都附加到提交消息的末尾，
在消息正文的“自由形式”（非结构化）部分之后。
这些是令牌-值（或键-值）对，通常由
冒号和空格 (:␣)。

就像我提到的，“签核”并不是当前实践中唯一的预告片。看
例如 此提交 ,
与“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]>

除了上面的“sign-off”预告片之外，还有：

• “Cc”（已通知补丁）
• “Acked-by”（代码所有者确认） ，“看起来不错”）
• “审阅者”（已审阅）
• “报告和测试者”（报告并测试了问题（我假设））

其他项目，例如 Gerrit，有自己的标题和
对他们来说有相关的意义。

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

这个故事的寓意

我的印象是，虽然这个故事的最初动机
特定的元数据是一些法律问题（从其他方面来看）
答案），此类元数据的实践已经超越了仅仅
处理形成作者链的情况。

[↑1]：man git-interpret-trailers
[↑2]：这些似乎有时也被称为“sob”（缩写）。