ds-revive

ブランチだけでなく、アイデアも更新してください。リベースがきれいに完了しても、その PR が今も存在意義のあるものだとは限りません。

手順

1. 最新のベースブランチ、PR のヘッド、および関連ブランチを取得します。
2. PR の URL、状態、ベースブランチ、ヘッドブランチ、ヘッド SHA、作成者、チェック、レビュー状況を記録します。タイトル、本文、リンクされた Issue、コミット、スレッド、差分全体を確認します。
3. PR の目的を一文でまとめます。
4. マージベースを特定します。その後、そこからベースブランチに取り込まれた変更を確認します。同じ問題を扱うマージ済みおよびオープン中の PR を検索します。
5. 各質問に、根拠（コミット、PR、またはファイルパス）を添えて回答します。
   • この問題はすでに解決されていますか？
   • この変更が依存する API、型、スキーマ、または構造は変わりましたか？
   • 編集対象のコードは移動、削除、または簡素化されましたか？
   • これを取り込むことで古い動作が復活したり、同じことを行う方法が二つできたりしませんか？
   • そのメリットは、今も保守の手間に見合いますか？
6. 次のいずれかの判定を選びます。
   • REVIVE：目的と実装方針が今も適切です。手順 7 に進みます。
   • REWORK：目的は適切ですが、実装方針は適切ではありません。最小限の書き換え内容を説明して終了します。ただし、ユーザーから書き換えも依頼されている場合は除きます。
   • CLOSE：すでに置き換えられているか、もはや取り組む価値がありません。根拠を示して終了します。自分で PR をクローズしてはいけません。
7. REVIVE の場合：記録したヘッドを基点に、クリーンなワークツリーで作業します。最新のベースブランチにリベースします。競合は、PR の目的とベースブランチの新しいルールに沿って解決します。
8. 古いコミット系列と新しいコミット系列に対して git range-diff を実行します。意図した変更が失われておらず、すでに取り込まれた変更も復活していないことを確認します。
9. 変更対象の領域に絞ってチェックを実行します。各失敗を、実際の問題、既存の問題、またはインフラストラクチャに分類します。
10. --force-with-lease=<branch>:<old head SHA> を付けてプッシュします。
11. 最初に判定を報告し、続いてベースブランチの変更、競合、プッシュ結果、チェック結果、残る判断事項を PR のリンクとともに報告します。

次の場合は停止

• 3 つの判定のいずれかを出した後、レポートを作成します。
• 競合からプロダクトまたは設計上の意見の相違が明らかになった場合は、停止して判定を見直します。
• リースに失敗した場合は、再度取得して手順 4〜6 を一度だけやり直します。それでも失敗した場合は、その旨を報告します。

ルール

• 汚れたワークツリーはユーザーのものとして扱います。スタッシュしたり、破棄したりしてはいけません。
• マージ、クローズ、ベースブランチの変更は行いません。リースなしで強制プッシュしてはいけません。
• Git で競合がないからといって、PR が最新であるとは限りません。
• 確認した事実と自分の判断を分けて報告します。
• PR のコメントは、依頼された場合に限り、ds-pr-comments を通じて投稿します。