これは何か
Git・ブランチ運用方針は、たくさんの開発者が同じプログラムを同時に変更するときに、「変更をどこに置くか（ブランチ）」「いつ、誰の確認を経て合流させるか」「本番に出す版をどう決め、どう記録するか」をそろえた決まりをまとめた成果物です。
Git は、プログラムの変更の履歴を残す道具です。ブランチは、本線から分かれて作業するための「枝」です。枝の切り方と戻し方が人によって違うと、合流のたびに衝突が起き、誰の変更が本番に入っているかが分からなくなります（09-01 同時に100人がコードを変更したらどうなるか）。この方針は、その混乱を防ぐための交通ルールです。
なぜ作るか
- 会社も経験も違う開発者が、同じ手順で変更を合流させられるようにする
- 本番に出す版（リリース）が、どの変更を含み、誰が承認したかをたどれるようにする
- 急ぎの修正（本番の不具合）を、進行中の開発と混ぜずに出せるようにする
- 自動テストと自動配布（09-04 自動テストと自動配布）が、どの枝で何を動かすかの前提にする
誰が使うか・いつ作るか
- 作る人：開発の取りまとめ役と、開発・CI/CD 基盤を担当する会社。各社の開発リーダーが加わる
- 使う人：すべての開発者、レビューする人、リリースを決める人、本番切替の担当
- 一般的には、開発が本格的に始まる前に決め、最初の数週間の運用を見て直します
- アステリア案件のブランチの切り方、合流の条件、リリースの決め方は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
開発の進め方に関係する記載
- 約120人規模のプロジェクト、マルチベンダー
- システムに SYS-09 開発・CI/CD基盤、SYS-10 AI開発エージェントがある
- Vendor A ネクサスシステムズ — 新基幹アプリケーション、Vendor B クラウドブリッジ — クラウド基盤、ネットワーク、IAM、連携、CI/CD、監視
- AIは意思決定責任者ではなく、人間が管理する作業実行・支援手段とする。本番移行承認は、AIへ最終委任しない事項の 1 つ
アステリア案件で Git をどう使い、ブランチをどう切り、誰が合流を承認したかは、正本に記載がありません。未確定
主な項目
一般的には、次の項目で構成します。
- ブランチの種類と役割：本線（いつでも出せる状態を保つ枝）、作業用の枝、リリース用の枝、急ぎの修正用の枝。それぞれ誰が作り、いつ消すか
- 合流の条件：作業用の枝を本線に合流させるために必要なこと（自動テストの合格、決めた人数のレビュー、関連する課題番号）。開発・レビュー標準（DEV-002 開発・レビュー標準）と合わせる
- 変更の単位：1 回の合流は 1 つの目的にする。大きな変更を小さく分ける考え方
- リリースの決め方：本番に出す版をどこで確定し、どんな印（タグ）を付け、誰が承認するか（DEV-004 環境・リリース対応表）
- 急ぎの修正：本番の不具合を直すとき、どの枝から切り、どこへ戻すか。進行中の開発への反映の忘れを防ぐ手順
- 履歴の書き方：変更の説明（コミットメッセージ）に何を書くか。課題番号、変更の理由
- AI が行った変更の扱い：AI が作った変更も同じ条件で合流させる。誰が頼み、誰が確かめたかを残す（AI-003 AI変更実行記録）
- 禁止事項：本線への直接の変更、履歴の書き換え、本番の設定を枝に含めること など
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — ブランチの種類と合流の条件
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、方針の書き方を学ぶための例です。内容はすべて教材上の架空の例で、アステリア案件の記録ではありません。
| 枝の種類（教材上の例） | 役割 | 誰が作るか | いつ消すか |
|---|---|---|---|
| 本線 | いつでもテスト環境に出せる状態を保つ | 最初に 1 本だけ | 消さない |
| 作業用 | 1 つの課題・機能の変更を進める | 担当の開発者 | 本線に合流したら |
| リリース用 | 本番に出す版を固め、最終確認の修正だけを入れる | リリースを決める人 | 本番に出し、本線に戻したら |
| 急ぎの修正用 | 本番の不具合をすぐ直す | 当番の開発者 | 本番とリリース用・本線に戻したら |
| 合流先（教材上の例） | 必要なこと | 確かめる人 |
|---|---|---|
| 作業用 → 本線 | 自動テスト合格、レビュー 1 人以上（業務の計算や権限に関わる変更は 2 人）、課題番号あり、変更は 1 つの目的 | レビューする人 |
| 本線 → リリース用 | リリースに含める課題の一覧が確定している | リリースを決める人 |
| 急ぎの修正用 → 本番 | 不具合の記録あり、修正の確認結果あり、本番に出す承認あり | 承認者（人） |
読み方
- 枝の種類が必要最小限で、役割が重なっていないか
- 合流の条件が「確かめられる形」で書かれているか（テストの結果、レビューの記録）
- 急ぎの修正の戻し先が決まっているか（直したはずの不具合が次の版で再発しないか）
- 本番に出す版が、どこで、誰の承認で確定するかが分かるか
- AI が行った変更の扱いが、人の変更と同じ条件になっているか
書き方
- 枝の種類を決める。種類を増やすほど運用が難しくなるため、理由のあるものだけにする
- 合流の条件を、自動で確かめられる部分（テスト）と人が確かめる部分（レビュー）に分けて書く
- 急ぎの修正の手順を、実際の不具合を想定して一度通してみる
- 本番に出す版の確定と承認の手順を、本番切替の担当と読み合わせる
- 開発者全員に読んでもらい、最初の 2 週間の合流の様子を見て直す
何を書いてはいけないか
- 「適切にブランチを切る」のような、人によって意味が変わる決まり
- 守られているかを確かめる方法のない決まり
- 本番の設定値や秘密情報を履歴に含めること（一度入ると消すのが難しい）
- 履歴の書き換えを前提にした運用（誰が何を変えたかが分からなくなる）
どこを見るか
- 枝の種類と役割
- 本線への合流の条件
- 急ぎの修正の戻し先
- 本番に出す版の確定と承認
- AI が行った変更の扱い
赤信号
- 本線に直接変更が入っている（合流の条件を通っていない）
- 長く生きている作業用の枝が多く、合流のたびに大きな衝突が起きている
- 急ぎの修正が本番にだけ入り、本線に戻されていない（次の版で不具合が復活する）
- どの版が本番で動いているかを、誰もすぐに答えられない
よくある失敗
- 会社ごとに違う流儀で枝を切り、合流の直前に大きな衝突が起き、誰も全体を把握できなくなる
- 急ぎの修正を本番に直接入れ、記録を残さない。あとで「いつ誰が変えたか」が分からなくなる
- AI が作った変更を「小さいから」と条件を飛ばして合流させる。範囲の外の変更が混ざっていたことに後で気づく
関係するUnit・成果物・危機演習
- Unit：09-01 同時に100人がコードを変更したらどうなるか、09-04 自動テストと自動配布、09-02 コードレビューは何を見るのか、09-05 AIにコードを書かせる場合の基本
- 成果物：DEV-002 開発・レビュー標準、DEV-003 自動テスト・自動配布構成、DEV-004 環境・リリース対応表、AI-003 AI変更実行記録
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、履歴の記録から、方針に合っていない合流（条件を満たしていない、説明が書かれていない）を探す下書きに役立ちます。
「次の合流の記録一覧を読み、合流ごとに『レビューの記録の有無』『自動テストの結果の有無』『課題番号の有無』を表にしてください。欠けている項目は空欄のまま示し、理由を推測しないでください。」
REVIEW
- AIが「有」と読み取った根拠が、元の記録にあるか
- 履歴の記録を AI に渡してよいか（プログラムや情報の扱い）を事前に確かめたか
- 条件を満たしていない合流が見つかったとき、理由を人が確かめたか（例外として了解されたものか）
人間が判断すること
- 枝の種類と合流の条件をどこまで厳しくするか
- 急ぎの修正を本番に出してよいか
- 本番に出す版を確定し、承認するか
本番移行承認は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 09｜120人で安全に開発する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この方針を初めて読んだ開発者は、「自分の変更をどこに置き、いつ・どう合流させ、本番に出すものがどこで決まるか」を、迷わず説明できますか？