web-dev-qa-db-ja.com

Git forのサインオフ機能とは何ですか？

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

git commit --signoff

仮にあったとしても、いつ使うべきですか？

gitgit-commit
493
Clark Gaebel

サインオフは、Linuxカーネルお​​よび他のいくつかのプロジェクトにパッチを適用するための要件ですが、ほとんどのプロジェクトは実際にはそれを使用しません。

それは SCO訴訟 、（そして SCOからの著作権侵害の他の告発 、それらのほとんどが実際には訴訟を起こしたことがない）を契機として導入されました。 開発者用原産地証明書 。これは、あなたが問題のパッチを作成したことを証明すること、あるいはあなたが知る限りでは適切なオープンソースライセンスの下で作成されたこと、または誰かからあなたに提供されたことを証明することを意味します。そうでなければそれらの条件の下で。これは、適切なフリーソフトウェア（オープンソース）ライセンスの下で公開されていない著作権保護コードがカーネルに含まれていないことを保証するために、問題のコードの著作権の状態について責任を負う人々の連鎖を確立するのに役立ちます。

475
Brian Campbell

サインオフは、コミットメッセージの最後に、誰がコミットの作者であるかを証明する行です。その主な目的は誰が何をしたかの追跡を改善することです、特にパッチで。

コミット例

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

62
Andrzej Rehmann

git 2.7.1（2016年2月）は、 David A. Wheeler（david-a-wheeler） で commit b2c150d （2016年1月5日）を明確にしています。
（ Junio C Hamano - gitster - in commit 7aae9ba に合併、2016年2月5日）

git commitのmanページ 現在の内容は次のとおりです。

-s::
--signoff::

コミットログメッセージの最後に、Signed-off-by行をコミッターで追加します。
承認の意味はプロジェクトによって異なりますが、通常、コミッターは同じライセンスの下でこの作品を送信する権利を持ち、開発者原産地証明書に同意します（詳しくは https://developercertificate.org を参照）。

--signoffを説明する文書を展開

--signoffが何を意味するのかをより詳細に説明するために様々なドキュメント（manページ）ファイルを修正します。

これは、pauljが指摘した「 新しい記事 'Bottomley：DCOに関するささやかな提案' 」（開発者原産地証明書）にヒントを得たものです。

私がDCOに関して抱えている問題は、git commitに "-s"引数を追加することがあるということではありません（DCO（ - git commitのmanページではDCOについては何も言及されていません）。実際に見ても構いません。

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

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

このサインオフはgit pullでも利用可能になりました（Git 2.15.x/2.16、Q1 2018用）。

W。Trevor King（wking） による commit 3a4d2c7 （2017年10月12日）を参照してください。
（ Junio C Hamano - gitster - in commit fb4cd88 、 2017年11月6日にマージ）

pull：--signoff/--no-signoffを "git merge"に渡します

マージは--signoffを取ることができますが、--signoffを引き下げることなくプルすると、使用するのは不便です。 'pull'がオプションを選択して通過させることを許可します。

28
VonC

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

ヘッダーまたはトレーラー（↑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]>

上記の「サインオフ」予告編に加えて、次のものがあります。

  • “ Cc”（パッチに関して通知された）
  • 「承認者」（コードの所有者から承認された、「私にはよさそうです」）
  • “レビュー投稿者”（reviewed）
  • 「報告されテストされた人」（問題を報告およびテストしました（私が想定しています））

例えばGerritのような他のプロジェクトはそれら自身のヘッダとそれらに関連する意味を持っています。

参照してください： https://git.wiki.kernel.org/index.php/CommitMessageConventions

この話の教訓

この特定のメタデータに対する最初の動機付けはいくつかの法的な問題（他の答えで判断）であったが、そのようなメタデータの実践は単なる著者の連鎖を形成する場合を扱う以上に進歩した。

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

14
Guildenstern