checkout-commit-push-pr

完全な Git ワークフロー

何をすべきか私に尋ねないでください。以下のワークフローに従ってください。例外は、疑わしい未追跡ファイルがある場合（手順 2）と、ローカルのデフォルトブランチが分岐している場合（手順 1）のみです。その場合は推測せず、作業を止めて報告してください。

1. 現在のブランチと変更を確認する

   次のコマンドで確認します。

   git status
   

   保留中の変更をすべて確認し、Git のコミットメッセージ／PR メッセージに反映します。通常の git diff で表示されるのは、追跡対象ファイルのステージされていない編集だけなので、すでにステージされている変更も確認してください。

   git diff
   git diff --staged
   

   コミットする予定の未追跡ファイルは、内容を読んでください。新しいファイルそのものが変更であり、内容を表示する diff コマンドはありません。

   リポジトリのデフォルトブランチを特定してください。main と決めつけてはいけません。

   # Fast and local (may error if origin/HEAD is unset on older clones)
   git symbolic-ref --short refs/remotes/origin/HEAD | sed 's|^origin/||'
   
   # Fallback if the above errors
   gh repo view --json defaultBranchRef -q .defaultBranchRef.name
   

   すでにデフォルト以外のブランチにいる場合は、そのブランチを使い続けてください。 新しいブランチを作成するのは、現在デフォルトブランチにいる場合のみです。名前が main、master、develop などのどれであっても、デフォルトブランチに直接コミットしたりプッシュしたりしてはいけません。

   デフォルトブランチにいる場合は、次の命名規則に従って新しいブランチを作成し、チェックアウトしてください。

   [optional LINEAR-IDENTIFIER-][2-4 descriptive words]-[MMDD]
   

   • LINEAR-IDENTIFIER (任意)：この作業に既知の Linear イシューがある場合は、その識別子をブランチ名の先頭に付けます（例：DATA-24-）。これにより、後続のツールがブランチ名からイシューを特定し、PR と相互リンクできます。
   • 2～4 語：修正する問題を表す語を、小文字でハイフン区切りにします。
   • 日付：今日の日付を MMDD 形式で指定します（例：7 月 12 日 → 0712）。

   例：

   • fix-sqlfluff-errors-1214（12 月 14 日）
   • update-dbt-models-0103（1 月 3 日）
   • DATA-24-improve-dagster-debug-skill-0527（イシュー識別子を先頭に付ける場合）

   ブランチを作成する前に、ローカルのデフォルトブランチが最新であることを確認してください。そうすることで、新しいブランチが古いコードをベースにするのを防げます（ベースが古いと、無関係な差分や PR での回避可能な競合が発生します）。未コミットのローカル変更があっても問題ありません。git pull --ff-only はそれらに影響しません。ローカルブランチが分岐しているために失敗した場合は、独断でリベースやマージをせず、作業を止めて報告してください。

   git pull --ff-only
   git checkout -b <new-branch-name-MMDD>
   

2. ファイルを慎重にステージし、内容が分かるコミットメッセージでコミットする：

   ファイルをステージする前に、手順 1 で git status が報告した内容を確認してください。

   • 変更／削除された追跡対象ファイル：すべてステージします。これらが提出する作業内容です。
   • 未追跡ファイル：変更に関係するものだけをステージします。シークレット、ローカル設定、一時的な出力と思われるファイル（例：.env*、credentials*、*.key、.DS_Store、エディターのスワップファイル、大容量データダンプ、一度限りのデバッグスクリプト）はステージしないでください。未追跡ファイルが判断しにくい場合は、まず内容を読んでください。
   • コミットに含めるべきか判断が難しいものがある場合は、推測せず、作業を止めて私に報告してください。

   # Stage all tracked changes
   git add -u
   
   # Stage intended untracked files explicitly, by name
   git add <new-file-1> <new-file-2>
   
   # Confirm exactly what will be committed
   git status
   git diff --staged --stat
   
   # Commit with descriptive message, informed by the diff from step 1
   git commit -m "<Overview of the change>
   
   - <item 1 in the more specific bulleted list of changes>
   - ...
   "
   

3. PR テンプレートを確認する：

   PR を作成する前に、リポジトリに PR テンプレートがあるか確認してください。

   # Check common PR template locations
   ls .github/pull_request_template.md .github/PULL_REQUEST_TEMPLATE.md PULL_REQUEST_TEMPLATE.md 2>/dev/null
   

   • テンプレートがある場合は、その内容を読み、PR 本文にテンプレートの構成を使用します。
   • テンプレートの必須セクションをすべて記入します。
   • テンプレートがない場合は、以下のデフォルト形式を使用します。

   この時点で Linear イシューが判明している場合（オーケストレーターから渡された場合（例：wrap-up-session）、または LINEAR-IDENTIFIER-… というブランチ名の接頭辞から自動検出された場合）は、PR 本文の上部にクローズ参照と **Ticket:** 行の両方を含めて、PR 作成時にイシューと関連付けられるようにしてください。

   Fixes DATA-24
   **Ticket:** [DATA-24](https://linear.app/citizen/issue/DATA-24)
   

   イシューの実際の URL を使用してください。PR によってイシューが完了する場合のみ Fixes を使用し、それ以外の場合は Refs を使用してください。両方の行を最初の見出しの直下に挿入してください（例：テンプレートを使用する場合は ## Description & motivation の直下）。イシュー識別子が不明な場合は、この行を省略してください。wrap-up-session から呼び出された場合、その後の linear-ticket-management 手順でイシューが作成または更新され、PR と相互リンクされます。単独で実行した場合は、イシューは作成されません。

4. ブランチをプッシュして PR を作成する：

   # Push to remote
   git push -u origin <new-branch-name-MMDD>
   
   # Create pull request (use template structure if found, otherwise use default)
   gh pr create --title "<Descriptive PR Title>" --body "$(cat <<'EOF'
   

Summary

• <what changed and why, in a few bullets>

Changes

• <specific change 1>
• ... EOF )"

  
  ヒアドキュメントの本文と終了記号 `EOF` は、先頭列（0 桁目）から始まることに注意してください。インデントされていると、`EOF` でヒアドキュメントが終了しません。
  
  **必ず PR へのリンクを出力してください**（`gh pr create` がリンクを表示します）。
  

5. CI/CD チェックを監視する： PR を作成したら、CI/CD パイプラインを監視し、すべてのチェックが合格することを確認します。

   # Block until all checks complete — no manual polling needed
   # (add --fail-fast to return as soon as any check fails)
   gh pr checks <PR-NUMBER> --watch
   
   # View detailed information about a specific workflow run
   gh run view <RUN-ID>
   
   # View logs for a failed job
   gh run view --log-failed --job=<JOB-ID>
   

   重要： gh pr checks は、次の 2 つのケースで終了コード 1 とともに「no checks reported」を返します。（a）リポジトリにワークフローがない場合、または（b）ワークフローは存在するものの、まだ登録されていない場合（プッシュ後、通常 10～30 秒）。この出力だけを見て「CI が設定されていない」と判断しないでください。

   • まず ls .github/workflows/ を実行します。ファイルが 1 つでもあれば CI は設定されているため、待つ必要があります。
   • 「ワークフローなし」と「保留中」を区別できる gh pr view <PR-NUMBER> --json statusCheckRollup を優先してください。
   • ワークフローが存在するのにチェックが表示されない場合は、約 30 秒待ってから再確認します。

   目標：必須チェックをすべて合格させること。 リポジトリで実行されるチェックがリンター、ビルド、テスト、ドキュメントの検証のいずれであっても、必須チェックの失敗はすべて自分で修正してください。

   チェックに失敗した場合の対応：

   • 失敗したジョブのログ（gh run view --log-failed）を確認し、チェック名から推測するのではなく、実際のエラーを特定します。
   • 問題をローカルで修正し、コミットして同じブランチにプッシュします。チェックは自動的に再実行されます。すべて合格するまで繰り返します。
   • 機械的な修正には、リポジトリ独自のツールを優先してください（たとえば、チェックで実行されるフォーマッターやリンターを実行し、自動修正機能があれば適用します）。
   • 失敗が自分の差分に起因しない場合（不安定なテスト、インフラストラクチャのエラー、先に作成する必要がある状態などの前提条件の不足）は、コミットを重ねて対応し続けず、作業を止めてその旨を報告します。

   スキップが許容されるチェック：

   • 非本番ブランチでの本番環境専用チェック
   • 変更内容に該当しない条件付きチェック

   すべてのチェックに合格した場合：

   • PR はレビューとマージの準備ができています。
   • すべての検証が成功し、コード品質が確保されています。

コミットメッセージの形式

• 1 行目： 変更の簡潔な要約
• 本文： 実施した具体的な変更を箇条書きで記載
• Co-Authored-By: Claude のトレーラー（または生成者を示すその他の帰属情報）は追加しないでください。