PRを置き換える

メンテナーが作成したPRがコントリビューターのオープンなPRを置き換える場合、帰属表示とプロセスの規律がコントリビューターとの健全な関係を維持します。このページはそのルールブックです。

まず、代替案を試してください。

Superseding は最も重いオプションです。1つを開く前に、次の順序で試してください：

修正をコントリビューターのブランチにプッシュする。 PR に maintainerCanModify: true（個人フォークからの PR ではデフォルト。gh pr view <number> --json maintainerCanModify で確認）が設定されている場合は、修正を直接プッシュしてコントリビューターの PR をマージします。git log、git blame、コントリビューターの GitHub プロフィールで貢献者の帰属がそのまま保たれます。修正が些細なものでない場合は、まずコントリビューターと調整してください。彼らに未プッシュの作業がある状態でプッシュすると、彼らが解決しなければならないコンフリクトが発生します。
具体的な変更を求めながらレビューを残してください。 コントリビューターが対応可能で、その修正が元の範囲内（clippy のリンティング、エッジケース、テスト追加など）であれば、変更を要求し、彼らが修正をプッシュするのを待ちましょう。1行の修正は、通常、上書きするよりも変更を要求する方が好まれます。
マージ後にフォローアップのPRを開く。 コントリビューターのPRがそのまま正しく、さらに堅牢化を望む場合は、まずマージしてから別のPRを開く。帰属は維持されますが、その代償として master に既知の問題が一時的に残る可能性があります。

次のいずれかが該当する場合のみ置き換えてください：

コントリビューターが応答しない（プロジェクトのレビューSLA内に返信がない）。
この変更には、コントリビューターの当初の範囲よりも大幅に多くの作業が必要です。
複数の関連するコントリビューターPRを、一貫性のある単一の変更として統合する必要があります。
コントリビューターはメンテナーによる編集を拒否（maintainerCanModify: false）しており、フォローアップのPRは現実的ではありません。

帰属ルール

上書きを行う際、実質的なコードや設計決定を引き継ぐ場合は、著作者を明示的に保持してください：

作業内容が実質的に取り込まれた、置き換え対象の貢献者ごとに Co-authored-by: Name <email> トレーラーを1つ追加します。GitHub が認識できるメールアドレスを使用してください。貢献者の <login@users.noreply.github.com> 形式、または検証済みのコミット用メールアドレスのいずれかを使用します。
コミットメッセージの末尾に空行を挟んで、トレーラーはそれぞれ別の行に記述します。トレーラーをエスケープされた \n テキストとしてエンコードしないでください。
PRの本文に、置き換えられたPRのリンクをリストし、それぞれから取り込まれた内容を簡潔に説明してください。
実際のコードや設計が取り込まれていない場合（着想を得ただけの場合）は、Co-authored-by を使用せず、代わりに PR の notes セクションでクレジットを記載してください。

これらのトラクターは、GitHub のコントリビューター認識を正しくルーティングします。これらがないと、元の著者は「クローズド」として表示され、引き継ぎの記録がありません。

PRのタイトルと本文のテンプレート

feat(<scope>): unify and supersede #<pr_a>, #<pr_b> [and #<pr_n>]

## Supersedes

- #<pr_a> by @<author_a>
- #<pr_b> by @<author_b>

## Integrated scope

- From #<pr_a>: <what was materially incorporated>
- From #<pr_b>: <what was materially incorporated>

## Attribution

- `Co-authored-by` trailers added for materially incorporated contributors: Yes/No
- If No, explain why

## Non-goals

- <explicitly list what was not carried over>

## Risk and rollback

- Risk: <summary>
- Rollback: <revert commit/PR strategy>

コミットメッセージのテンプレート

feat(<scope>): unify and supersede #<pr_a>, #<pr_b> [and #<pr_n>]

<one-paragraph summary of integrated outcome>

Supersedes:
- #<pr_a> by @<author_a>
- #<pr_b> by @<author_b>

Integrated scope:
- <subsystem_or_feature_a>: from #<pr_x>
- <subsystem_or_feature_b>: from #<pr_y>

Co-authored-by: <Name A> <login_a@users.noreply.github.com>
Co-authored-by: <Name B> <login_b@users.noreply.github.com>

置き換えられたPRを閉じる

各PRを、新しいPR名と引き継ぎ内容をコメントで閉じるようにしてください：

Superseded by #<new_pr>. Your work is incorporated as `Co-authored-by` —
specifically the <X> approach in <Y>. Thanks for the original take here;
closing this one in favor of the unified PR.

コントリビューターが元のPRで特定の設計選択に対して異議を唱え、その後の改訂が異なる方向に進んだ場合は、それを明示的に記載してください。実際には再設計であるにもかかわらず、それがスムーズな継承であるかのように振る舞わないでください。

ハンドオフテンプレート（エージェント → エージェント、またはエージェント → メンテナー）

フライト中に引き継ぐ作業には、以下を含めてください：

変更点
変更点なし。
検証実行と結果。
残りのリスク / 不明点。
次に推奨されるアクション。

これは、複数の作業セッションにまたがる上書き、メンテナ間のエージェント支援による引き継ぎ、および1人の人が別の人の進行中のブランチを引き継ぐ必要があるあらゆるケースに適用されます。

Keyboard shortcuts