commit-and-push

コミットとプッシュ

出力言語： 回答や作成する成果物は、ユーザー自身の言語で記述してください（リポジトリの履歴ではなく、ユーザーのメッセージに合わせてください）。

概要

4つの手順があり、ほとんどのセッションでは最初の2つだけで十分です。

1. コミット 作業を、レビュー担当者が1つずつ確認できる単位に分けてコミットします
2. プッシュ 機能ブランチをプッシュします。保護されたブランチには決してプッシュしないでください
3. MR/PR を同期 既存のものは自動で更新し、新規作成する前には確認を求めます
4. タグ付けとリリース 実際にバージョンをリリースするときに限ります

このファイルは各手順への案内です。各手順にはそれぞれ専用のリファレンスがあります。

手順	内容	リファレンス
コミット	ワークスペース／ブランチの確認、バッチ分割、Conventional Commits 形式のメッセージ、プッシュ	references/commit.md (§0–§3)
MR/PR	ベースライン、テンプレートの選択、下書き、検出／作成／更新、内容の再確認	references/mr-pr.md (§4–§4.5)
リリース	リポジトリのバージョン／タグ規約の確認、リリース済みコミットへのタグ付け、リリースの作成／更新	references/release.md (§6)
ホスト CLI	gh／glab コマンドと、余計なやり取りを招く落とし穴	references/host-cli.md
文体	各文章の対象読者と、その表現の出典	references/voice.md

MR/PR のテンプレートは assets/ にあります。それぞれ必須の4つのセクションと「該当する場合のみ追加」のリストで構成されています。feature-to-integration.md は QA 用、integration-to-production.md は本番環境へのリリース用、hotfix-to-production.md はホットフィックス用です。

基本原則：1つのコミットには、レビュー担当者が単独で判断できる変更を1つだけ含めます。1つの PR には、確認が必要な人に向けて説明された、リリース可能なストーリーを1つだけ含めます。1つのリリースには、実際にリリースされたコミットのタグを1つだけ付けます。

テスト設計の判断（test-design を参照）や TDD のリズム（superpowers:test-driven-development を参照）に取って代わるものではありません。

使用するタイミング

• ユーザーがコミット／プッシュ／「コミットしてプッシュ」／PR または MR の下書き作成やオープンを指示したとき
• ユーザーがタグ付け／バージョンのリリース／リリースの公開を指示したとき、またはプロモーション MR がマージされたとき
• ワーキングツリーに、1つのコミットに含めるべきではない複数の関心事が混在しているとき
• PR／MR の読者に作業の確認方法を伝える説明が必要なとき

使用しないタイミング： リリースの意図がないレビューのみの場合、またはテスト設計のみの場合（test-design を使用してください）。（上流のゲートでレビューを提案され、ユーザーが辞退した場合は、ユーザーの判断に従って進めてください。）

鉄則（譲れない原則）

1. NEVER commit or push to a protected branch (default: main, master, pro, test — plus any the repo declares).
2. NEVER mix unrelated changes in one commit.
3. EVERY commit message MUST be `type(scope): subject` (Conventional) and say what changed, not which files.
   Language is free (Chinese/English); the format is not.
4. EVERY PR/MR description MUST tell its reader how to check the work.
5. NEVER create a NEW MR/PR or release without an explicit yes. ALWAYS sync an EXISTING one — that part is automatic.
6. NEVER trust exit 0 after writing an MR/PR body or release notes. Read it back and compare.
7. NEVER invent a version scheme — follow the repo's tag history; if there is none, ask.

文言どおりに守らないことは、原則に反することです。「test に手早く1つだけコミットする」「Test plan は後で追加する」「今回だけは強制プッシュしても大丈夫」などは認められません。

実行時のワークフロー

「Using commit-and-push to …」と宣言してから、実際に実行する各ステップを TODO にします。通常はステップ 1～4 を実行し、作業上必要な場合にのみ 5～7 を実行します。

1. ワークスペース、ブランチ、アップストリームを確認する（commit.md §0）— 保護されている場合は中止します。
2. バッチを計画する（commit.md §1）— 計画を示します。デフォルトで実行し、変更をどのバッチに含めるか不明な場合にのみ確認します。
3. 各バッチをコミットする（commit.md §2）— そのバッチだけをステージします。コミットメッセージでは 理由 を説明します。文体は、この会話から採取したサンプルに基づく voice.md に従います。git の履歴は参照しません。
4. フィーチャーブランチをプッシュする（commit.md §3）— 強制プッシュの前には確認します。
5. MR/PR の草案を作成する（mr-pr.md §4）— ブランチの役割から MR が何をするのか（QA の準備／本番環境へのリリース／ホットフィックス）を判断し、該当する assets/ テンプレートを使って、ベースライン以降の すべての コミットを網羅します。
6. 同期する（mr-pr.md §4.5）— このブランチの既存 MR/PR（マージ済みのものも含む）を探します。見つかった場合は更新して内容を読み返し、見つからない場合は作成前に確認します。
7. タグ付けとリリース（release.md §6）— 依頼された場合、またはプロモーション MR がマージされ、このリポジトリがマージ時にリリースする場合に実行します。

その後、コミット、プッシュ結果、MR/PR の番号と URL、リリース URL、未ステージの項目を 報告 します。

よくある言い訳（そして実際のところ）

言い訳	実際のところ
「大きなコミット 1 つのほうが速い」	レビュアーが変更を二分探索したり、きれいに取り消したりできません。意図ごとにバッチ分けします。
「今回だけテストのためにプッシュする」	保護されているブランチは保護されています。フィーチャーブランチと MR を使います。
「テスト計画は後でいい／明らかだ」	チェックリストがなければ、「完了」は主張であって事実ではありません。
「強制プッシュで履歴を整理できる」	まず確認します。保護されたブランチでは決して実行しません。
「フックが邪魔なので --no-verify でスキップする」	原因を修正します。フックのスキップはリリースではありません。
「フックに拒否されたコミットを amend する」	コミットは行われていません。amend すると 前の コミットが書き換えられます。修正してから再度コミットします。
「PR の説明文は最後のコミットメッセージと同じ」	PR が説明するのは baseline..HEAD の変更全体です。
「コミットは英語だけが正しい」	形式は固定ですが、言語はユーザーに合わせます。
「git の履歴からユーザーの文体を調べる」	その履歴の大半は AI が書いたものです。現在の会話からサンプルを採取します。
「CI が動くように .env をコミットする」	シークレットは決してコミットしません。警告して、未ステージのままにします。
「MR はすでにあるので、同期は不要」	古い説明文は誤った内容です。既存の MR はプッシュのたびに同期します。
「確認せずに MR を作成すればいい」	作成すると公開され、元に戻すのが困難です。作成前に確認します（mr-pr.md §4.5）。
「ブランチの先端にタグを付ける」	リリースされたコミットにタグを付けます。通常は本番環境のマージコミットです。
「バージョン番号を適当に選ぶ」	リポジトリのタグ履歴に従います。履歴がなければ確認します。

ツールの落とし穴は言い訳ではなく、まだ把握していないことです。 実測された gh／glab の注意点（-f と -F の違い、mr list --state、mr view <branch>、未プッシュのタグ、既存のタグに対する release create）は host-cli.md §Traps に記載されています。ホスティングサービスのコマンドを実行する前に読んでください。

チェックリスト

• 保護ブランチではないこと。上流ブランチも保護されていないこと
• 各バッチが1つの変更であること。各メッセージが type(scope): subject の形式で、理由を記載していること。シークレットをステージングしていないこと
• origin <feature-branch> のみにプッシュしていること。依頼されていない --force や --no-verify を使っていないこと
• ベースラインがMRのターゲットブランチであること。baseline..HEAD が空でないこと。件数は git rev-list --count から取得していること（マージを含む）
• このMRの内容に合ったテンプレートを使っていること。必須の4セクションを記入し、該当しないセクションは「なし」とだけ記載せず、省いていること
• タイトルと概要が、ベースライン以降のすべてのコミットを網羅していること
• すでに実行したことと未対応のことを、どちらも具体的に記載していること。未実行のことを実行済みとして記載していないこと
• このブランチに既存のMR/PRがないか確認していること（マージ済みのものも含む）。見つかった場合は同期済みであること（ship-to-productionでは本文を維持し、件数のみ更新）。見つからなかった場合は、まず確認を依頼していること
• MR/PRの本文を読み返して、書き込み後の内容と一致することを確認していること — 終了コード0を信用していないこと
• （リリースする場合）バージョンがリポジトリのタグ履歴に従っていること。リリースしたコミットにタグが付いていること。タグを個別にプッシュしていること。リリースを検証していること（release.md §6）