Git - パッチ提出に関するドキュメント

パッチ提出は2.46.0で最後に更新されました

ガイドライン

このプロジェクトに貢献するためのガイドラインを以下に示します。また、これらのガイドラインの多くを網羅したステップバイステップのチュートリアルも用意されています。

典型的なパッチシリーズのライフサイクル

後述する様々なガイドラインの背景にある理由を理解するために、まずこのプロジェクトにおける典型的なパッチシリーズのライフサイクルがどのように進むかを理解しましょう。

あなたは「かゆみ」を思いつきます。あなたはそれをコード化します。そのためには、プロジェクトからの事前の承認は必要ありません。

あなたのパッチはメーリングリスト上の他の貢献者によってレビューされ、レビューは、あなたのパッチの背後にある一般的なアイデア（「そもそも解決する価値のある問題を解決しているのか？」を含む）、ソリューションの設計の背後にある理由、そして実際の実装など、様々な事柄のメリットを評価するために行われます。ここで示されているガイドラインは、レビュー担当者が理解しやすいようにすることで、あなたのパッチを支援するためのものです。
あなたはパッチをリストに送り、変更について知る必要がある人にCCを送ります。あなたの目標は、必ずしもあなたが構築しているものが良いことを他人に納得させることではありません。あなたの目標は、あなたが一人で構築できるものよりも優れた「かゆみ」の解決策を考え出すための助けを得ることです。

知る必要がある人は、あなたが修正しているコードに取り組んだ人です。これらの人々は、あなたを助けるのに十分な知識を持っている可能性が最も高い人ですが、あなたを助ける義務はありません（つまり、あなたは彼らに助けを求めますが、要求しません）。 git log -p -- $area_you_are_modifying は、彼らが誰なのかを知るのに役立ちます。
あなたはコメントや改善のための提案を受け取ります。あなたは「あなたのパッチの上に」パッチの形でそれらを受け取るかもしれません。更新されたパッチセットを準備する際に、それらを考慮しながら、メーリングリストで「全員に返信」で応答することが期待されています.
パッチを磨き、洗練し、リストとあなたのパッチの改善に時間を費やしてくれた人々に再送信します。ステップ(2)に戻ります。
上記の反復作業によってパッチが改善される一方で、メンテナーはリストからパッチを取得し、seen ブランチにキューに入れることがあります。これは、人々が自分のツリーにパッチを取得して適用することなく、パッチを試すことを容易にするためです。seen に入っていることには、他に意味はありません。具体的には、パッチが何らかの形で「受け入れられた」ことを意味するものではありません。
議論がパッチの最新イテレーションが十分な状態であるというコンセンサスに達すると、メンテナーは、週に数回メーリングリストに送信される「What's cooking」レポートにトピックを含め、「next にマージ予定」とマークします。この決定は、主にレビューの議論に参加した人々の助けを借りて、メンテナーによって行われます。
パッチが next ブランチにマージされた後も、さらにパッチを追加することで議論を継続し、改善することができますが、トピックが next にマージされるまでに、全員がトピックの範囲と基本的な方向性が適切であることに同意していることが期待されているため、このような段階的な更新は小さな修正と洗練に限定されます。トピックが next で一定期間（7日間など）クックされ、さらに微調整が必要なくなった後、master ブランチにマージされ、次のメジャーリリースの一部になるのを待ちます。

以下のセクションでは、このようなライフサイクルの中で、あなたのパッチが効果的にレビューされるのを助けるための多くのテクニックと慣習が列挙されています。

開始点を選択する。

予備的なステップとして、まず作業の開始点を選択する必要があります。これは通常、ブランチを選択することを意味しますが、技術的には特定のコミット（通常はブランチのHEAD、つまり先端）です。

gitworkflows[7]で説明されているように、認識しておくべき重要なブランチがいくつかあります。すなわち、4つの統合ブランチがあります。

maint
master
next
seen

リストの下位にあるブランチは、通常、上位にあるブランチの子孫です。たとえば、master は通常 maint の上にパッチ（コミット）を持っているため、maint は master よりも「古い」ブランチです。

また、他の貢献者からの作業を含む「トピック」ブランチもあります。トピックブランチは、メーリングリスト上の現在の着信寄稿のセットを整理するために、Gitメンテナーによって（彼らのフォークで）作成され、定期的な「What's cooking in git.git」のアナウンスに項目化されています。トピックブランチの先端を見つけるには、git log --first-parent master..seen を実行し、マージコミットを探します。このコミットの2番目の親がトピックブランチの先端です。

適切な開始点を選択するための指針となる原則が1つあります。一般的に、変更が関連する最も古い統合ブランチを常に作業の基盤にしてください（gitworkflows[7]の「上向きにマージする」を参照）。この原則は、ほとんどの場合、新しい作業の開始点は、以下のケースに基づいて maint または master の最新のHEADコミットであるべきであることを意味します。

リリースされたバージョンのバグを修正する場合は、maint を開始点として使用します（これは、最近 master に登場したがリリースされたバージョンでは利用できなかった新しいAPI機能を使用せずに修正する必要があることを意味する場合があります）。
それ以外の場合は（新しい機能を追加する場合など）、master を使用します。

注記

例外的なケースとして、古いバージョンで導入されたバグを、最近のリリースよりもはるかに古いリリースのユーザーのために修正する必要がある場合があります。 git describe --contains X は、バグを導入したコミット X を v2.30.0-rc2-gXXXXXX と記述するかもしれず、そのバグの影響が非常に大きいため、「Git 2.41.0」が現在のリリースである場合、Git 2.30.xシリーズの新しいメンテナンスリリースを発行する必要があるかもしれません。このような場合、2.30.xシリーズのメンテナンスブランチの先端を使用することをお勧めします。これは、メンテナーの「ブレークアウト」リポジトリの maint-2.30 ブランチにある可能性があります。

これはまた、あなたの作品が master に昇格する現実的なチャンスを持ちたいのであれば、next や seen はあなたの作品の不適切な開始点であることを意味します。それらは単に新しい作業の基盤として使用されるように設計されていません。それらは、進行中のトピックがうまく連携することを確認するためだけに存在します。そのため、next と seen の両方が、メーリングリスト上の着信パッチと頻繁に再統合され、以前のバージョンの自身を置き換えるために強制的にプッシュされます。文字通り next の上に構築されたトピックは、next 内の他のすべてのトピックを引きずり込むことなく master にマージすることはできません。それらのいくつかは準備ができていないかもしれません。

例えば、ツリー全体に変更を加えているときに、他の誰かが独自のツリー全体への変更を加えている場合、作業内容が他のユーザーの作業と大きく重複する可能性があります。このような状況では、`next` を開始点として使用したくなるかもしれません（他のユーザーの作業が含まれているため）。しかし、そうすると、他のユーザーの作業だけでなく、他の貢献者からの他のランダムなものが `next` に統合されているものすべてに依存することになります。そして、`next` が新しいバージョンで更新されるとすぐに、メンテナによってクリーンに適用されるためには、すべての作業をリベースする必要があります。

`master` にはないが `next` に既にある少数のトピックブランチにどうしても依存しなければならないという、本当に例外的な状況下では、`master` をフォークして必要なトピックブランチをマージすることで、独自のカスタムベースブランチを作成することができます。そして、このベースブランチの上で作業することができます。ただし、このベースブランチは自分だけが知っていることに注意してください。そのため、パッチをリストに送信する準備ができたら、カバーレターに作成方法を必ず伝えてください。この重要な情報は、他のユーザーがあなたの作業を試すために、自分の環境でベースブランチを再作成することを可能にします。

最後に、システムの一部には、独自のソースコードリポジトリを持つ専任のメンテナがいることに注意してください（以下の「サブシステム」セクションを参照）。

論理的に separate な変更は別々のコミットにしましょう。

パッチが本当に些細なものでない限り、作業ツリーとコミットヘッドの間で生成されたパッチを送信しないでください。代わりに、常に完全なコミットメッセージでコミットを作成し、リポジトリから一連のパッチを生成してください。これは良い習慣です。

変更の説明は、実際にパッチのテキストを読んでコードが説明どおりに動作するかどうかを確認しなくても、人々がそれが良いことかどうかを判断できる程度に詳細にしてください。

説明が長くなりすぎる場合は、コミットをより細かい部分に分割する必要があるというサインです。そうは言っても、レビュアーがパッチをチェックし、将来のメンテナがコードを理解するのに役立つ事項を明確に記述したパッチが、最も美しいパッチです。主題の要点をうまくまとめ、変更の動機、変更によって取られたアプローチ、および関連する場合は以前のバージョンとどのように大きく異なるかを記述する説明は、すべて良いことです。

修正しているバグのテストがあることを確認してください。ガイダンスについては、`t/README` を参照してください。

新しい機能を追加する場合は、新しいテストを行い、機能が新しい動作をトリガーすべきときにトリガーすること、および機能がトリガーすべきでないときにトリガーしないことを示してください。コードを変更した後、テストスイート全体がパスすることを確認してください。バグを修正する場合は、他の誰かが誤って修正した内容を壊した場合に、回帰を避けるために壊れる新しいテストがあることを確認してください。また、作業を *next* と *seen* にマージして、テストがまだパスすることを確認してください。他のユーザーがまだ作業中のトピックは、あなたが自分のトピックで行おうとしていることと予期しない相互作用をする可能性があります。

https://github.com/git/git のフォークにプッシュすると、CI 統合を使用して Linux、Mac、Windows で変更がテストされます。詳細はGitHub CIセクションを参照してください。

更新された動作を記述するためにドキュメントを更新し、結果のドキュメントセットが適切にフォーマットされていることを確認することを忘れないでください（Documentation/doc-diff スクリプトを試してください）。

現在、スペルと文法に関して、米国と英国の英語の規範が混在しており、やや残念な状況です。しかし、至る所のファイルに触れて不整合を修正するだけの巨大なパッチは歓迎されません。そのようなパッチから生じる可能性のある他の変更との潜在的な衝突は、それだけの価値はありません。小さな、消化しやすいパッチで、周辺の他の実際の作業（例えば、段落を分かりやすく書き直しながら、en_UK のスペルを en_US に変更するなど）の副作用として、徐々に米国英語に統一することを好みます。明白な誤植の修正（"teh" → "the"）は、他のドキュメントの変更とは別に独立したパッチとして提出されることがより歓迎されます。

ああ、もう一つ。私たちは空白にうるさいです。変更が `templates/hooks--pre-commit` に同梱されているサンプルの pre-commit フックでエラーをトリガーしないことを確認してください。これが発生しないようにするには、コミットする前に変更に対して `git diff --check` を実行してください。

変更内容を分かりやすく説明してください。

変更を説明するログメッセージは、変更自体と同じくらい重要です。コードは、周囲のコードとどのように動作するかを十分に説明するインコードコメントで明確に記述されているかもしれませんが、将来コードを修正または拡張する必要がある人は、コードがそのように動作する *理由* を知る必要があります。理由はいくつかあります。

コードが意図したとおりに動作していない可能性があります。実際に何を達成したかったのかを書き留めておくことで、コードを修正し、本来あるべき動作をするようにすることができます（また、ログメッセージを書いて考えをまとめる際に、自分のバグを発見することもよくあります）。
コードが、あなたの当面のニーズに必要なことだけを行っている可能性があります（例えば、ファイルに対して何をするかを実装または設計せずに、「ディレクトリに対して X を行う」）。コードが何をして *いない* のかを書き留めておくことで、将来の開発者の指針となります。「ディレクトリは特性 Y を持っているので、ディレクトリに対して X を行います」と書き留めておくと、「ああ、ファイルも特性 Y を持っているので、ファイルに対しても X を行うのは理にかなっているかもしれません」と推測するのに役立ちます。「... なので、ファイルに対して同じ X を行いません」と言うと、その推論が妥当かどうかを判断するのに役立ちます（その場合、ファイルをカバーするためにコードを拡張する時間を無駄にしません）。そうでない場合は、ファイルをカバーするためにコードを拡張する理由を説明できます）。

ログメッセージの目標は、将来の開発者を支援するために、変更の背後にある *理由* を伝えることです。レビュアーは、提案されたログメッセージがこの目的に合致しているかどうかも確認します。

コミットメッセージの最初の行は短い説明（50文字がソフトリミットです、git-commit[1] の DISCUSSION を参照）で、ピリオドを省略する必要があります。また、ほとんどの場合、最初の行に "area: " というプレフィックスを付けるのが慣例です。ここで、area はファイル名または変更されるコードの一般的な領域の識別子です。例：

doc: sign-off と pgp-signing の違いを明確にする
githooks.txt: イントロセクションを改善する

どの識別子を使用するか迷う場合は、変更しているファイルに対して `git log --no-merges` を実行して、現在の規則を確認してください。

"area:" プレフィックスの後のタイトルの文は、文末にピリオドを付けず、最初の単語は大文字で始まりません（大文字の省略は、タイトルの "area:" プレフィックスの後の単語にのみ適用されます）。文の最初の単語であるという理由以外に大文字にする理由がない限り。例えば、"doc: Clarify..." ではなく "doc: clarify..."、または "githooks.txt: Improve..." ではなく "githooks.txt: improve..."。しかし、"refs: HEAD is also treated as a ref" は正しいです。なぜなら、文の途中に現れる場合でも `HEAD` はすべて大文字で表記するからです。

本文は、意味のあるコミットメッセージを提供する必要があります。

変更によって解決しようとしている問題、つまり変更がない場合の現在のコードの何が問題なのかを説明します。
変更によって問題が解決される方法、つまり変更後の結果がなぜ優れているのかを正当化します。
検討されたが破棄された代替ソリューションがあれば、それを示します。

現状を説明する問題ステートメントは、現在形で書かれています。"The code used to do Y when given input X" の代わりに "The code does X when it is given input Y" と書いてください。"Currently" と言う必要はありません。問題ステートメントの現状は、プロジェクトの慣例により、変更 *なし* のコードに関するものです。

変更内容は命令形で記述してください。例えば、"[This patch] makes xyzzy do frotz" や "[I] changed xyzzy to do frotz" の代わりに "make xyzzy do frotz" と記述します。まるでコードベースに動作を変更するように命令しているかのように。説明は外部リソースなしで理解できるようにしてください。メーリングリストアーカイブへの URL を提供する代わりに、議論の関連点をまとめてください。

履歴の「より安定した」部分（つまり、`maint`、`master`、`next` などのブランチ）にある別のコミットを参照したい理由はいくつかあります。

修正しているバグの根本原因を導入したコミット。
拡張している機能を導入したコミット。
テストのために `next` と `seen` に作業のトライアルマージを行ったときに、作業と競合したコミット。

より安定したブランチ（`master`、`maint`、`next` など）のコミットを参照する場合は、"abbreviated hash (subject, date)" の形式を使用してください。例：

	Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30)
	noticed that ...

gitk の「コミット参照をコピー」コマンドを使用してこの形式を取得できます（件名は二重引用符で囲まれています）。または、`git show` のこの呼び出しを使用します。

	git show -s --pretty=reference <commit>

または、--pretty=reference をサポートしていない古いバージョンの Git では、

	git show -s --date=short --pretty='format:%h (%s, %ad)' <commit>

`Signed-off-by` トレーラーを追加して作業を証明する

誰が何をしたかを追跡しやすくするために、パッチに「署名」することで、パッチを書いた、または私たちと同じライセンスでパッチを渡す権利があることを証明するようにお願いしています。署名がないと、パッチを受け入れることができません。

以下の D-C-O を証明する場合（かつその場合のみ）

開発者原産地証明書 1.1

このプロジェクトに貢献することにより、私は以下を証明します。

貢献は、全体または一部が私によって作成されたものであり、ファイルに示されているオープンソースライセンスの下で提出する権利があります。または

貢献は、私の知る限り、適切なオープンソースライセンスで保護されている以前の作業に基づいており、そのライセンスの下で、全体または一部が私によって作成された変更を加えた作業を、同じオープンソースライセンス（異なるライセンスで提出することが許可されていない限り）の下で提出する権利があります。ファイルに示されているとおり。または

貢献は、(a)、(b)、または (c) を証明した他の誰かから直接提供されたものであり、私はそれを変更していません。

私は、このプロジェクトと貢献が公開されており、貢献の記録（私が提出したすべての個人情報、署名を含む）が無期限に保持され、このプロジェクトまたは関連するオープンソースライセンスに従って再配布される可能性があることを理解し、同意します。

コミットに "Signed-off-by" トレーラーを追加します。これは次のようになります。

	Signed-off-by: Random J Developer <random@developer.example.org>

この行は、-s オプションを付けて git-commit コマンドを実行すると、Git によって追加できます。

他人のパッチを転送する際には、上記のD-C-Oルールに従って、自身のSigned-off-byトレーラーを付与することができます。実際には、そうすることを推奨します。変更を真の作者に適切に帰属させるために、本文の冒頭に"From: "行を配置することを忘れないでください（上記の(2)を参照）。

この手順は元々Linuxカーネルプロジェクトに由来するため、私たちのルールは彼らのルールと非常によく似ています。しかし、パッチに署名するという意味はプロジェクトごとに異なり、あなたが慣れ親しんでいるプロジェクトのルールとは異なる場合があります。

また、Signed-off-byトレーラーには実名が使用されていることに注意してください。実名を隠さないでください。

必要に応じて、最後に追加のタグを付けることができます。

Reported-by: は、パッチが修正しようとしているバグを見つけた人に功績を認めるために使用されます。
Acked-by: は、パッチが修正しようとしている領域に精通している人がパッチを気に入ったことを示します。
Reviewed-by: は、他のタグとは異なり、レビュー担当者が詳細な分析の後、パッチに完全に満足した場合にのみ提供できます。
Tested-by: は、パッチを適用した人が目的の効果があることを確認したことを示すために使用されます。
Co-authored-by: は、提出前にパッチのドラフトを複数人で交換したことを示すために使用されます。
Helped-by: は、パッチ形式で正確な変更を提供することなく、変更のアイデアを提案した人に功績を認めるために使用されます。
Mentored-by: は、メンターシッププログラム（例：GSoCまたはOutreachy）の一環としてパッチの開発を支援した人に功績を認めるために使用されます。
Suggested-by: は、パッチのアイデアを提案した人に功績を認めるために使用されます。

状況によっては独自のトレーラーを作成することもできますが、代わりに上記で強調表示されているこのプロジェクトの一般的なトレーラーのいずれかを使用することをお勧めします。

タグの最初の文字だけを大文字にします。つまり、「Signed-Off-By」ではなく「Signed-off-by」、「Acked-By」ではなく「Acked-by:」を優先します。

コミットからGitツールを使用してパッチを生成します。

Gitベースのdiffツールは、推奨される形式であるunidiffを生成します。

パッチにファイルの名前変更が含まれている場合、git diffまたはgit format-patchに-Mオプションを使用することを恐れる必要はありません。受信側で問題なく処理できます。

パッチにコメントアウトされたデバッグコードを追加したり、パッチが達成しようとしているものと関係のない余分なファイルを含めたりしないでください。生成後、パッチを確認して正確性を確保してください。送信する前に、「開始点の選択」セクションで選択した開始点に正しく適用されることを確認してください。

注記	パッチをレビューする人の観点からは、`master`ブランチがデフォルトの開始点として想定されています。そのため、別の開始点を選択した場合は、カバーレターでこの選択を伝えてください。

パッチの送信。

レビュー担当者の選択

注記	セキュリティに関連する可能性のあるパッチは、公開メーリングリストではなく、Git Securityメーリングリスト¹に非公開で送信する必要があります。

パッチを"To:"をメーリングリストに設定し、"cc:"に触れている領域に関係する人をリストして（contrib/contacts/²にあるgit-contactsスクリプトは、それらを特定するのに役立ちます）、コメントとレビューを依頼します。また、トピックの試用マージをnextとseenに行ったときに、変更と競合する他の人の作業に気付いたかもしれません。これらの人々は、あなたが触れている領域をよく知っている可能性があります。

send-emailを使用している場合は、次のようにgit-contactsの出力をフィードできます。

	git send-email --cc-cmd='perl contrib/contacts/git-contacts' feature/*.patch

リストがパッチを適用するのが良い考えであるというコンセンサスに達した後、"To:"をメンテナー³に設定し、"cc:"をリスト⁴に設定して再送信します。これは、メンテナーが議論にあまり参加せず、レビューを信頼できる他の人に任せた場合に特に関連します。

パッチを支援してくれた人に功績を認めるために、Acked-by:、Reviewed-by:、Tested-by:などのトレーラーを追加し、そのような最終バージョンを送信するときに"cc:"にそれらを追加することを忘れないでください。包含のために。

`format-patch`と`send-email`

可能であれば、format-patchとsend-emailの使い方を学んでください。これらのコマンドは、パッチを送信するワークフローに最適化されており、既存の電子メールクライアント（多くの場合、「multipart/*」MIMEタイプの電子メールに最適化されています）がパッチを使用できなくなる可能性のある多くの方法を回避します。

注記	ここでは、`format-patch`と`send-email`を使用した手順の概要を示しますが、代わりにGitGitGadgetを使用してパッチを送信することもできます（MyFirstContributionを参照）。

Gitメーリングリストの人々は、あなたが送信した変更を読み、コメントできる必要があります。開発者が標準の電子メールツールを使用して変更を「引用」して、コードの特定の部分にコメントできるようにすることが重要です。このため、各パッチは個別のメッセージで「インライン」で送信する必要があります。

パッチシリーズのすべての後続バージョンとその他の関連パッチは、読者がシリーズのすべてのパーツを見つけやすくするために、独自の電子メールスレッドにグループ化する必要があります。そのため、追加の「カバーレター」メッセージ（下記参照）、最初のパッチ、またはそれぞれ前のパッチへの返信として送信します。パッチシリーズの更新バージョンを送信する方法についてのステップバイステップガイドを次に示します。

ログメッセージ（Signed-off-byトレーラーの名前を含む）がASCIIで記述できない場合は、正しいエンコーディングでメッセージを送信してください。

警告	MUAのワードラップによってパッチが破損する可能性があることに注意してください。パッチをカットアンドペーストしないでください。注意しないと、タブが失われる可能性があります。.

件行の先頭に[PATCH]を付けるのが一般的な慣例です。これにより、人々はパッチと他の電子メールの議論を容易に区別できます。パッチの性質を説明するために、括弧内にPATCHに加えてマーカーを使用することも推奨されます。例：[RFC PATCH]（RFCは「コメントのリクエスト」を表します）は、パッチが承認される前にさらに議論が必要であることを示すためによく使用されます。[PATCH v2]、[PATCH v3]などは、以前に送信した内容の更新を送信するときによく見られます。

git format-patchコマンドは、電子メールメッセージの本文を書式設定するための現在のベストプラクティスに従います。パッチの冒頭には、Signed-off-byトレーラーで終わるコミットメッセージと、3つのダッシュで構成される行、diffstat情報、パッチ自体が続きます。他人からのパッチを転送する場合は、オプションで、電子メールメッセージの冒頭、コミットメッセージが始まる直前に、「From:」行を置いてその人を指名できます。件名のデフォルトの「[PATCH]」を「[<text>]」に変更するには、git format-patch --subject-prefix=<text>を使用します。ショートカットとして、--subject-prefix="RFC PATCH"の代わりに--rfcを使用するか、--subject-prefix="PATCH v<n>"の代わりに-v <n>を使用できます。

コミットメッセージ自体以外に、パッチに関する追加の説明を追加することがよくあります。このような「カバーレター」資料は、3つのダッシュの行とdiffstatの間に配置します。複数回のレビューと議論が必要なパッチの場合、各反復間の変更の説明をGitノートに保存し、git format-patch --notesを介して3つのダッシュの行の後に自動的に挿入できます。.

これは実験的です.

トピックを送信するときは、トピックが取り上げられたときに「What's cooking」レポートに表示される1段落の概要を提案できます。そうする場合は、リリースノートにうまく収まる2〜5行の段落を書いてください（Documentation/RelNotes/*ファイルの多くの箇条書きのエントリを参照）、そしてそれをカバーレターの最初の段落にしてください。単一パッチシリーズの場合は、前述のように、3つのダッシュの行とdiffstatの間のスペースを使用します。

パッチをMIME添付ファイルとして添付しないでください。圧縮の有無にかかわらず。電子メールクライアントでquoted-printableを送信しないでください。電子メールクライアントでformat = flowedを送信しないでください。これは、パッチの空白を破壊します。多くの一般的な電子メールアプリケーションは、MIME添付ファイルを常にプレーンテキストとして送信するとは限らず、コードにコメントすることができません。 MIME添付ファイルの処理にも少し時間がかかります。これは、MIMEで添付された変更が受け入れられる可能性を低下させるわけではありませんが、延期される可能性が高くなります。

例外：メーラーがパッチを改ざんしている場合、誰かがMIMEを使用して再送信するように求める場合があります。それは問題ありません。

パッチにPGP署名しないでください。おそらく、メンテナーまたはリスト上の他の人はあなたのPGPキーを持っておらず、とにかくそれを取得しようとしないでしょう。あなたのパッチはあなたが誰であるかによって判断されません。不明なソースからの優れたパッチは、既知の、尊敬されるソースからのパッチよりも、受け入れられる可能性がはるかに高くなります。パッチが不十分に作成されているか、間違ったことを行っている場合

どうしてもPGP署名付きパッチを作成したい場合は、-----BEGIN PGP SIGNED MESSAGE-----で始まるtext / plainメッセージではなく、「multipart / signed」としてフォーマットしてください。それはtext / plainではなく、何か他のものです。

競合の処理とパッチの反復

パッチに加えられた変更を修正する場合、他の進行中のトピックとの競合の可能性を認識することが重要です。これらの潜在的な競合を効果的にナビゲートするには、以下に示す推奨手順に従ってください

適切なベースブランチに基づいてビルドし、上記のセクションを参照して、シリーズをformat-patchします。前回からの更新をその場で行うために「rebase -i」を実行している場合、これは以前のベースを再利用するため、（2）と（3）は些細なことになる可能性があります。

最後のラウンドがキューに入れられた場所のベースを見つけます

$ mine='kn/ref-transaction-symref'
$ git checkout "origin/seen^{/^Merge branch '$mine'}...master"

format-patchの結果を適用します。 2つのケースがあります
1. 問題が正常に適用され、テストも正常に完了します。（4）に進みます。
2. 問題が正常に適用されますが、ビルドまたはテストが失敗するか、問題が正常に適用されません。
  
  後者の場合、古いベースと（1）でビルドに使用したベースの違いに起因するテキストまたはセマンティックの競合があります。何が破損の原因となったのかを特定します（たとえば、（2）で使用されたベースから（1）で使用されたベースまでの間に、1つまたは2つのトピックがマージされた可能性があります）。
  
  最新の* origin/master *をチェックアウトし（これは（2）で使用されたベースよりも新しい可能性があります）、そこで新しく依存するトピックを「merge --no-ff」し、マージの結果をベースとして使用します。シリーズを再構築して、もう一度テストします。最後のそのようなマージからトピックの先端までformat-patchを実行します。もしあなたがしたなら
  $ git checkout origin/master $ git merge --no-ff --into-name kn/ref-transaction-symref fo/obar $ git merge --no-ff --into-name kn/ref-transaction-symref ba/zqux ... rebuild the topic ...
  次に、これらの「準備」マージの上にトピックを書式設定します。例：
  $ git format-patch "HEAD^{/^Merge branch 'ba/zqux'}"..HEAD
  カバーレターにこれを行ったこと、および* master *に加えてベースに含まれているトピックを書き込むことを忘れないでください。次に、（4）に進みます。
トピックの試用マージを* next *および* seen *に作成します。例：
```
$ git checkout --detach 'origin/seen'
$ git revert -m 1 <the merge of the previous iteration into seen>
$ git merge kn/ref-transaction-symref
```
トピックの以前の反復がすでに* seen *にある場合（この場合のように）、「revert」が必要です。以前の反復を除外しながら、master..origin/seenを最初から再構築することを選択できます。これは、メンテナー側で何が起こるかをより厳密にエミュレートする可能性があります。

この試用マージは競合する可能性があります。これは主に、*他の*トピックがトピックとどのような競合を起こすかを確認するためです。つまり、トピックを* master *で動作させるために依存する必要はありません。トピックが他のトピックの前に* next *に移動する場合、競合を解決するのは他のトピックの所有者の仕事になる可能性があります。

カバーレターで見つけた競合についてメモしてください。必ずしも解決する必要はありませんが、関連分野で他の人が何をしているのかを学ぶ良い機会になります。
```
$ git checkout --detach 'origin/next'
$ git merge kn/ref-transaction-symref
```
これは、あなたのトピックが、すでに進行中の他のトピックとどのような競合があるかを確認するためです。(3)-2 が更新された master と _next_ から取得した依存トピックの上にベースを作成した場合、競合は発生しません。状況が深刻な場合（確認方法の一つは、古いイテレーションで同じトライアルマージを試すことです。同様の競合が発生する可能性があります）、メンテナ側で処理されることを期待してください（手に負えなくなった場合は、パッチを受け取ったときにリベースを依頼します）。

専任メンテナがいるサブシステム

システムの一部には、独自のレポジトリを持つ専任のメンテナがいます。

git-gui/ は、Johannes Sixt によってメンテナンスされている git-gui プロジェクトからのものです。
```
https://github.com/j6t/git-gui
```

gitk-git/ は、Paul Mackerras の gitk プロジェクトからのものです。

git://git.ozlabs.org/~paulus/gitk

Those who are interested in improving gitk can volunteer to help Paul
maintain it, cf. <YntxL/fTplFm8lr6@cleo>.

po/ は、ローカライゼーションコーディネーターである Jiang Xin からのものです。
```
https://github.com/git-l10n/git-po/
```

これらの部分へのパッチは、それぞれのツリーに基づいている必要があります。

Jean-Noël Avila が率いる「Git ドキュメント翻訳」プロジェクトは、Git のドキュメントページを翻訳しています。彼らの成果物は、私たちのツリーの一部としてではなく、このプロジェクトとは別に管理されています。
```
https://github.com/jnavila/git-manpages-l10n/
```

GitHub CI

GitHub のアカウントがあれば、GitHub CI を使用して Linux、Mac、Windows で変更をテストできます。最近の CI 実行例については、https://github.com/git/git/actions/workflows/main.yml を参照してください。

初期設定の手順は以下のとおりです。

https://github.com/git/git を GitHub アカウントにフォークします。フォークの詳細な手順はこちらをご覧ください：https://help.github.com/articles/fork-a-repo/

初期設定後、GitHub 上の Git のフォークに新しい変更をプッシュするたびに CI が実行されます。すべてのブランチのテスト状態は、https://github.com/<あなたの GitHub ハンドル>/git/actions/workflows/main.yml で確認できます。

ブランチがすべてのテストケースに合格しない場合、緑色のチェックマークではなく、赤い x でマークされます。その場合は、失敗したジョブをクリックして「ci/run-build-and-tests.sh」または「ci/print-test-failures.sh」に移動できます。また、デバッグに関連するテストデータを含む tar アーカイブ（または zip アーカイブ）を含む zip アーカイブである「Artifacts」をダウンロードすることもできます。

問題を修正し、修正を GitHub フォークにプッシュします。これにより、すべてのテストに合格することを確認するための新しい CI ビルドがトリガーされます。

MUA 固有のヒント

私が受け取ったり、リストからピックアップしたりするパッチの一部には、共通の破損パターンがあります。MUA が空白を破損しないように正しく設定されていることを確認してください。

git-format-patch[1] の「DISCUSSION」セクションで、パッチを自分にメールで送信し、git-am[1] で適用することでパッチを確認するためのヒントを参照してください。

ついでに、パッチ適用試験実行の結果のコミットログメッセージを確認してください。結果のコミットの内容が、あなたが期待するものと正確に一致しない場合、メンテナがあなたのパッチを適用するときに、ログメッセージを手動で編集することになる可能性が非常に高くなります。「こんにちは、これは私の最初のパッチです。\n」のようなものは、コミットメッセージの終わりを示す 3 つのダッシュの後に記述する必要があります（パッチメールに本当に含めたい場合）。

Pine

(Johannes Schindelin)

I don't know how many people still use pine, but for those poor
souls it may be good to mention that the quell-flowed-text is
needed for recent versions.

... the "no-strip-whitespace-before-send" option, too. AFAIK it
was introduced in 4.60.

(Linus Torvalds)

And 4.58 needs at least this.

diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1)
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date:   Mon Aug 15 17:23:51 2005 -0700

    Fix pine whitespace-corruption bug

    There's no excuse for unconditionally removing whitespace from
    the pico buffers on close.

diff --git a/pico/pico.c b/pico/pico.c
--- a/pico/pico.c
+++ b/pico/pico.c
@@ -219,7 +219,9 @@ PICO *pm;
	    switch(pico_all_done){	/* prepare for/handle final events */
	      case COMP_EXIT :		/* already confirmed */
		packheader();
+#if 0
		stripwhitespace();
+#endif
		c |= COMP_EXIT;
		break;

(Daniel Barkalow)

> A patch to SubmittingPatches, MUA specific help section for
> users of Pine 4.63 would be very much appreciated.

Ah, it looks like a recent version changed the default behavior to do the
right thing, and inverted the sense of the configuration option. (Either
that or Gentoo did it.) So you need to set the
"no-strip-whitespace-before-send" option, unless the option you have is
"strip-whitespace-before-send", in which case you should avoid checking
it.

Thunderbird、KMail、Gmail

git-format-patch[1] の「MUA 固有のヒント」セクションを参照してください。

Gnus

*Summary* バッファの "|" は、現在のメッセージを外部プログラムにパイプするために使用できます。これは git am を駆動する便利な方法です。ただし、メッセージが MIME エンコードされている場合、プログラムにパイプされるのは、MIME の展開後に *Article* バッファに表示される表現です。これは、2 つの理由から、多くの場合、あなたが望むものではありません。非 ASCII 文字（特に人の名前）と空白（パッチでは致命的）がおかしくなる傾向があります。"|" を使用してパイプを実行する前に "C-u g" を実行してメッセージを生の形式で表示すると、この問題を回避できます。

1. Git セキュリティメーリングリスト: git-security@googlegroups.com

2. `contrib/` の下のスクリプトは、コアの `git` バイナリの一部ではなく、直接呼び出す必要があります。Git コードベースのクローンを作成し、`perl contrib/contacts/git-contacts` を実行してください。

3. 現在のメンテナ: gitster@pobox.com

4. メーリングリスト: git@vger.kernel.org

セットアップと設定

プロジェクトの取得と作成

基本的なスナップショット

ブランチとマージ

プロジェクトの共有と更新

検査と比較

パッチ適用

デバッグ

メール

外部システム

サーバー管理

ガイド

管理

低レベルコマンド