ブランチ戦略のポリシーについて述べる。具体的なブランチ戦略（e.g., Git Flow, GitHub Flow, etc)には踏み込まない。
ブランチ戦略の目的
コードの品質と本番環境の安定性を、開発フローの構造によって担保する。
- オペミスやAIの暴走によってコードの破壊や開発中のコードがリリースされるのを防ぐため、本番用のブランチを保護する
- 品質保証のため、本番への変更は必ずレビューとCIによる自動テストを経てから行う
- 後から追跡しやすいようブランチを用途によって区分する
また、これらは極力仕組みで保証し、個人の注意力に頼らないようにする。
ブランチ戦略とマージ戦略
なるべく独自戦略は避け、広く知られたブランチ戦略を用いる。実績に支えられた品質が期待できること、メンバーの学習コストを軽減できることが理由である。
どの戦略を用いるとしても、運用のブレを最小限に抑えられるよう、なるべくカスタマイズを避ける。
混乱防止のため、マージ戦略も同一のリポジトリでは単一のマージ戦略を用いる。その場その場で異なるマージ戦略を用いたり、あるいは複数のマージ戦略を混入させない。
命名規則
原則として採用したブランチ戦略の命名規則に従う。
命名規則は極力自動検証する（例：Git hook / CI）。
バージョン番号はセマンティックバージョニングで統一する（例: 1.2.0）。
仕組みによる強制
いずれのルールも仕組みによっておのずから守られるようにする。品質と保守性向上のため開発ルールは極力守られるべきであるが、人の注意力あるいはAIのプロンプト順守には100%を期待し得ない。これらの仕組みはGitHub Rulesetのような元から用意されている仕組みだけでなく、Git フックやGitHub Actionsのように後から追加できる仕組みを用いる。
例）
- GitHub Ruleset によるmainブランチの保護
- Gitフックによるコミットメッセージの整形
- GitHub Actionsによる自動テストの強制
緊急時・想定外のケースのため管理者が保護ルールをバイパスする仕組みは残しておく。ただし常時バイパスできる必要はなく、ブレイクグラス方式でもよい。
バイパスした際は、その理由を後で追えるよう理由を記録する（コメントでよい）
常にバイパスが必要になる運用は問題であるため是正する。
ルールの管理
属人性の防止・トレーサビリティの向上のため、保護ルールは極力IaCで管理し手動での設定変更を避ける。どうしても避けられない場合は記録を残す。
リリース方法
- オペレーション品質向上のため、リリースは人手を挟まずにCI/CDで完結させる。
- 逆に人手を介する運用（例：タグを切る際に担当者が元のコミットとバージョンを手入力する）は避ける。