Gitのサインオフ機能のポイントは何ですか？

git commit --signoff

いつ使用するべきですか？

サインオフは、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

git 2.7.1（2016年2月）では、David A. Wheeler（）によるコミットb2c150d（2016年1 月5日）でそれを明確にしています。^{（合併によりJunio C浜野- -でコミット7aae9ba、2016年2月5日）}david-a-wheeler
gitster

git commitマニュアルページに含まれるもの：

-s::
--signoff::

Signed-off-byコミッターのコミットログメッセージの最後に行を追加します。
サインオフの意味はプロジェクトによって異なりますが、通常はコミッターが同じライセンスの下でこの作業を提出する権利を有していることを証明し、開発元の証明書に同意します（詳細については、https：//developercertificate.orgを参照してください）。

説明するドキュメントを展開 --signoff

さまざまなドキュメント（マニュアルページ）ファイルを変更して、詳細を説明する --signoff意味を。

これは、pauljが指摘した「lwnの記事「Bottomley：DCOに関するささやかな提案」」（開発者証明書）に触発されました。

私はDCOに持っている問題があるということです「追加-sgitのは本当にあなたもDCOの聞いたことがあるという意味ではありませんコミットに」引数を（manページは、DCOのどこにも述べていない）、実際にそれを見ていない気にしません。git commit

では、「signed-off-by」の存在は、送信者がDCOに同意してコミットしていることをどのように意味するのでしょうか。事実と合わせて、SOBなしのパッチに対するリストへの返信を見て、「これを再送信してsigned-off-byコミットできるようにする」以外の何も述べていません。

gitのドキュメントを拡張すると、開発者がgit --signoffを使用するときに理解したと主張しやすくなります。

このサインオフは現在（Git 2.15.x / 2.16、2018年第1四半期）でも利用可能であることに注意してくださいgit pull。

W. Trevor King（）によるcommit 3a4d2c7（2017年10月12日）を参照してください。^{（合併によりJunio C浜野- -でfb4cd88コミットし、2017年11月6日）を}wking
gitster

pull：--signoff/--no-signoff「git merge」に渡す

mergeはをとることができますが--signoff、pullを渡さない--signoffと、使用するのに不便です。' pull'がオプションを取得して通過することを許可します。

この質問にはいくつか良い答えがあります。私は、より広い答えを追加しようとしています。つまり、現在の慣行では、これらの種類のライン/ヘッダー/トレーラーについてです。特にサインオフヘッダーについてはそれほどではありません（それだけではありません）。

「サインオフ」（↑2）のようなヘッダーまたはトレーラー（↑1）は、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 <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>

上記の「サインオフ」トレーラーに加えて、以下があります。

• 「Cc」（パッチについて通知された）
• 「Acked-by」（コードの所有者によって承認され、「私にはよさそうだ」）
• 「校閲者」（校閲済み）
• 「報告され、テストされた」（問題が報告され、テストされたと思います）

たとえばGerritなどの他のプロジェクトには、独自のヘッダーとそれらに関連する意味があります。

見る： https //git.wiki.kernel.org/index.php/CommitMessageConventions

この話の教訓

この特定のメタデータの最初の動機はいくつかの法的問題（他の回答によると判断）でしたが、そのようなメタデータの実践は、著者の連鎖を形成する場合を扱うことを超えて進んでいるように思います。

[↑1]：man git-interpret-trailers
[↑2]：これらは「sob」（イニシャル）と呼ばれることもあります。