jww-git-workflow

Git ワークフロー

まず、リポジトリ固有の指示に従ってください。ブランチ名、リモート、チェック、プルリクエストの規約については、リポジトリ固有の指示を唯一の基準としてください。Git の状態を変更する前に、それらを読んでください。

このスキルでは、環境から提供される一般的な Git の安全ルール（無関係な作業の保持、破壊的なリモート変更前の承認、CLI 出力の逐語的な記録）を前提としています。加えて、次のことを定めます。

• 提供する動作を明記したコミットタイトルを付け、差分から理由が明らかでない場合は本文も記載します（「コミットのワークフロー」を参照）。
• ベースをマージするのではなく、フィーチャーブランチをベースにリベースします。
• プルリクエストのフィードバックは、後続のコミットではなく、該当する既存のコミットを修正して反映します。
• プッシュによって公開済みブランチを書き換える場合は --force-with-lease を使用し、上書きする前に古くなったリースに対処します。
• 検証済みのブランチをプッシュし、PR を作成または更新することは通常の手順であり、個別の承認は不要です。マージ、削除、その他のリモート変更には引き続き承認が必要です。

Git の状態を変更する前に

1. git status、現在のブランチ、関連するリポジトリの指示を確認します。
2. 無関係な変更は保持します。必要な承認を得ずに作業を破棄したり、履歴を整理したりしないでください。コミットの修正は、コミットのワークフローで指示されている場合にのみ行います。
3. 調査中の作業と完了した実装を分けます。ステージングしてコミットするのは、後者だけです。

コミットのワークフロー

1. 目的の差分を確認し、完了した変更に属するファイルだけをステージングします。
2. リポジトリで必要とされる検証を実行し、コミットする前にステージ済みの差分を確認します。
3. 各コミットの内容に一貫性を持たせます。既存のプルリクエストや進行中の作業にフィードバックを反映する場合は、Justin またはリポジトリの規約で別々のコミットが必要とされる場合を除き、後続のコミットを追加するのではなく、該当する既存のコミットを修正します。
4. 提供する動作を説明する、大文字で始まる命令形のタイトルを付けます。実装段階や変更したファイルではなく、動作を説明してください。末尾にピリオドを付けず、約 60 文字以内にします。タイプやスコープのプレフィックスは使いません。
5. 差分から理由が明らかでない場合は、必ず本文を追加します。セキュリティ、並行性、デフォルトの変更、および既存の動作を削除または制限する変更では、必ず本文を追加してください。まず問題を説明し、次に変更内容を説明してから、読者に必要な影響を記載します。コミット本文は 72 桁で折り返し、変更ファイルを列挙しないでください。
6. コミットメッセージで、改行として文字列 \\n をそのまま使わないでください。複数行のメッセージでは、一時ファイルに実際の改行を記述し、git commit --file でコミットします。コミット後に git log -1 --format=%B で保存されたメッセージを確認します。
7. コミットで issue を解決する場合は、最終行に Closes #231 や Fixes #253 のような issue 参照をちょうど 1 つ記載して締めくくります。アシスタント、モデル、エージェント、ツールに言及せず、生成元を示すトレーラーも追加しないでください。
8. 統合したコミットのメッセージは、最終的な作業チェックポイントではなく、提供する機能を説明する内容に書き換えます。

更新と公開

1. リポジトリで明示的に別の方法が定められている場合を除き、ベースブランチをフィーチャーブランチにマージするのではなく、フィーチャーブランチをリモートのベースブランチにリベースします。
2. プッシュする前に、ブランチ、リモート、送信する正確なコミットを確認します。
3. 検証済みのフィーチャーブランチをプッシュし、それによって Justin の依頼が完了する場合は、プルリクエストを作成または更新します。この通常の公開手順に個別の承認は不要です。明示的な承認なしに、マージ、ブランチやタグの削除、リポジトリ設定の変更、その他の破壊的なリモート変更を行ってはいけません。
4. コミットの修正で公開済みブランチを書き換える場合は、--force-with-lease を使う場合に限りフォースプッシュします。リースが古くなっている場合は、リモートの作業をフェッチして比較してから、どう進めるかを判断します。同等の作業や並行して行われた作業を上書きせず、保持してください。

プルリクエストと GitHub

1. 一般的なガイダンスに従う前に、リポジトリ固有のプルリクエスト要件に従ってください。
2. 意思決定に関わる Git および GitHub CLI の出力は、特にエラーやリモート状態の競合について、原文のまま保持してください。
3. レビューのフィードバック、CI の失敗、プルリクエストのトリアージには、ハーネスの GitHub 統合または gh CLI を使用してください。コネクターや CLI の出力に含まれていない情報が含まれていると主張しないでください。

レビューと CI のフォローアップ

現在の差分、レビューの議論、失敗したチェックの出力に基づいて、対応可能なフィードバックを解決してください。欠陥と、古くなった指摘、すでに対処済みの指摘、根拠のない指摘を区別し、却下した指摘については根拠を示して説明してください。

修正にはコミットワークフローを使用してください。対処済みの指摘、残っているブロッカー、公開済みの最新コミットに関連するチェックとフィードバックを報告してください。CI がキューに入っている場合や実行中の場合は未完了です。ローカルでの検証だけでは、マージ可能であることの証明にはなりません。依頼されない限り、再レビューを依頼しないでください。

ブランチとワークツリーの整理

現在のリモートおよびプルリクエストの証拠から、どのブランチとワークツリーが不要かを判断してください。スカッシュマージやリベースマージも考慮してください。Git のマージ済みブランチ一覧に表示されないからといって、未マージであるとは限りません。また、プルリクエストがクローズされていても、その変更が取り込まれたとは限りません。すでに取り込まれたブランチが、アクティブな作業のベースになっている場合もあります。保持候補とその理由を報告してください。

依存関係のある作業の分割

明示的なベースと実際の依存関係を示し、独立してレビューできる成果を作成してください。履歴を書き換える前に、復元可能な参照を保持してください。分離が求められた場合は、無関係なワーキングツリーの変更を専用のブランチまたはワークツリーに保持してください。

各成果の差分を、意図したベースに対して確認し、前提条件の欠落、変更の重複、無関係な作業がないかを検証してください。影響を受ける各成果について、リポジトリの検証ワークフローを使用してください。機能を単独で成立させられない依存関係は保持し、その内容を説明してください。更新と公開の手順に従い、公開済みのプルリクエストのベースと説明が分割内容と一致するようにしてください。