変更要約: AZ-400 第2章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
2.1Git とブランチ戦略
ソース管理の基盤——Git（分散バージョン管理）、ブランチ戦略（trunk-based / GitHub Flow / GitFlow）、フィーチャーブランチ、マージ vs リベース——を理解します。チームで安全に並行開発します。
DevOps の土台はソース管理です。Git を中心に、チームに合うブランチ戦略で並行開発を安全に進めます。
2.1.1Git とブランチ戦略
- trunk-based：main へ小さく頻繁に統合。短命なブランチ。CI/CD と相性が良い。
- GitHub Flow：main＋短命フィーチャーブランチ＋PR。シンプルで継続的デリバリー向き。
- GitFlow：main/develop/feature/release/hotfix の多層。厳格なリリース管理向き。
- マージ vs リベース：マージは履歴を保持、リベースは履歴を直線化する。
「小さく頻繁に統合＝trunk-based（CI/CD 向き）」「シンプルな main＋PR＝GitHub Flow」「多層で厳格なリリース＝GitFlow」「履歴保持＝マージ、直線化＝リベース」 は AZ-400 で頻出です。長命なブランチはマージ地獄を招くため、短命ブランチ＋頻繁な統合が推奨されます。
大きなバイナリは Git LFS で管理し、リポジトリの肥大化を防ぎます。モノレポ/マルチレポはチーム構造と依存関係に応じて選びます。
AZ-400 は「チームとデリバリー目標に合うブランチ戦略を選び、CI/CD と整合させる」設計力を問います。trunk-based development は main（トランク）へ小さく頻繁に統合し、ブランチを短命（数時間〜数日）に保つことでマージコンフリクトと統合リスクを最小化——フィーチャーフラグで未完成機能を隠しつつ本番ブランチを常にリリース可能に保つのが定石で、CI/CD と最も相性が良いです。GitHub Flow は main＋短命フィーチャーブランチ＋PR のシンプルな継続的デリバリー型。GitFlow は develop/release/hotfix を持つ多層モデルで、明確なリリースサイクルや複数バージョン併存が要る製品向きですが、長命ブランチがマージ負担を増やすため近年は trunk-based が推奨される傾向です。履歴管理は、マージ（マージコミットで分岐履歴を保持）とリベース（コミットを付け替えて直線化）を使い分け、共有済みブランチのリベースは履歴改変になるため避けます（squash マージで PR を 1 コミットに集約する運用も一般的）。大きなバイナリは Git LFS（ポインタ＋別ストレージ）で扱い、モノレポ（統合・横断変更が容易だがスケールに工夫が要る）とマルチレポ（独立・疎結合だが横断変更が面倒）をチーム構造と依存で選びます。設計の要は、短命ブランチ＋頻繁な統合＋PR レビュー＋CI を基本線に、製品のリリース要件に応じて戦略を調整することです。
| 戦略 | 特徴 | 向くケース |
|---|---|---|
| トランクベース | main へ小さく頻繁・短命ブランチ・フラグ | 高頻度 CI/CD・継続的デプロイ |
| GitHub Flow | main＋短命ブランチ＋PR | シンプルな継続的デリバリー |
| GitFlow | develop/release/hotfix の多層 | 明確なリリースサイクル/複数版 |
| マージ vs リベース | 履歴保持 / 直線化 | 監査重視 / 履歴の見やすさ重視 |
シナリオ：1 日に何度も本番デプロイしたい SaaS チームで、マージコンフリクトと統合の遅れに悩んでいる。→ trunk-based development を採用し、ブランチを短命（その日のうちにマージ）に保つ。未完成の機能はフィーチャーフラグで隠して main を常にリリース可能に。PR にはビルド検証（CI）と必須レビューを課し、squash マージで履歴を整理。長命な develop ブランチ（GitFlow）は廃止して統合の遅延を解消します。
FAQ：マージとリベース、どちらを使う？ 共有ブランチ（main 等）にはマージが安全で、分岐の履歴と監査性を保てます。自分のローカルな未共有フィーチャーブランチを最新化するときはリベースで直線的な履歴を作れます。原則「公開済みの履歴はリベースしない」。PR 統合時に squash マージを使えば、フィーチャー内の細かいコミットを 1 つに集約して main の履歴を読みやすく保てます。
ひっかけ：「CI/CD を高頻度で回したい」のに GitFlow の長命な develop/feature ブランチを選ぶのは逆効果——長命ブランチは統合を遅らせマージ地獄を招きます。高頻度デリバリーには trunk-based（短命ブランチ＋フラグ）が正解。また、共有済みの main をリベースして履歴を書き換えるのは厳禁（他者の履歴を壊す）です。
2.1.2この節のまとめ
- 戦略＝trunk-based / GitHub Flow / GitFlow
- 統合＝短命ブランチ＋頻繁な統合／履歴＝マージ vs リベース
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. CI/CD を最大限に活かすため、main へ小さく頻繁に統合する短命ブランチ中心の戦略を採りたい。どれですか？
Q2. main・develop・release・hotfix など多層のブランチで厳格にリリース管理したい。どの戦略ですか？
Q3. フィーチャーブランチの履歴を main に取り込む際、履歴を直線的に整理したい。どの操作ですか？