第2章 · リポジトリの操作·v1.1.0·更新 2026/6/15·読了目安 約7分
変更要約: 本文を拡充（図解を追加）
2.4GitHub Flow（変更を届ける基本の型）
この節の要点
個人でもチームでも使える軽量なブランチ運用「GitHub Flow」を学びます。ブランチ作成 → コミット → Pull Request → レビュー → マージ → デプロイという流れと、各段階の意味を押さえます。
ここまでに学んだ道具（ブランチ・コミット・Pull Request）を、実際の開発でどう組み合わせるのでしょうか。その標準的で軽量な「型」が GitHub Flow です。難しいルールはなく、小さく安全に変更を届けるための流れです。
2.4.1GitHub Flow の6ステップ
- ブランチ作成：
mainから短命の feature ブランチを切る。 - コミット：意味のある単位で変更を記録する。
- Pull Request：変更を提案し、議論やレビューを始める。
- レビュー / 議論：フィードバックを反映し、CI の自動チェックを通す。
- マージ：承認されたら
mainへ統合する。 - デプロイ：
mainの内容を反映・公開する。
2.4.2なぜこの型が良いのか
mainを常にデプロイ可能な状態に保てる。- 変更が小さく、レビューしやすく安全。
- PR に議論と履歴が残り、後から経緯を追える。
- CI と組み合わせれば、マージ前に自動チェックできる。
コツ
ブランチは小さく短命に保ち、こまめに PR を出しましょう。小さな PR ほどレビューもマージも速く、コンフリクトも起きにくくなります。
注意
main へ直接 push しないのが基本です（ブランチ保護で禁止できます）。長生きするブランチは main から乖離し、コンフリクトの原因になります。
試験ポイント
GitHub Flow の順序（branch → commit → PR → review → merge → deploy）、「main は常にデプロイ可能に保つ」、「短命ブランチ＋PR で統合」は頻出です。
2.4.3この節のまとめ
- GitHub Flow＝ブランチ作成 → コミット → PR → レビュー → マージ → デプロイ
mainは常にデプロイ可能に保ち、作業は短命の feature ブランチで行うmainへ直接 push せず、PR とレビューを通して統合する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. GitHub Flow の最初のステップはどれですか？
Q2. GitHub Flow における main ブランチの扱いとして正しいものはどれですか？
Q3. 変更を main へ取り込む前に通すべきものはどれですか？