現場実践｜GitHub・Git Flow実践

Git FlowとGitHub運用ガイド｜チームで使うブランチ戦略とPull Requestベースの開発フロー

「GitのブランチってどんなルールでつければいいのI?」「コードレビューの流れを整備したい」——Git Flow・GitHub Flow・Trunk-Based Developmentのブランチ戦略の違いと、Pull Requestベースのチーム開発フローを解説します。

読了目安：約18分更新日：2026年4月

💡 Gitのブランチ戦略はチームの開発速度・リリースの安全性・コードレビューの質に直結します。チームの規模・リリース頻度に合ったブランチ戦略を選ぶことが重要です。

この記事を書いた人

現役ITエンジニア・IT講師（経験14年）

CCNA・CCNP 取得LPIC-1 保有SES現場を複数経験

チームのGit運用設計・PRレビュー文化の整備を複数プロジェクトで担当してきた立場から解説します。

1. 主要なブランチ戦略の比較

戦略	特徴	向いているチーム
Git Flow	main/develop/feature/release/hotfixの5種類のブランチ	バージョン管理が重要な製品・リリース頻度が低いチーム
GitHub Flow	main+feature branchのシンプルな構成	継続的デプロイ・小規模チーム・Web系サービス
Trunk-Based	全員が1つのブランチ（trunk）に頻繁にマージ	CI/CDが高度に自動化されたSRE・大規模チーム

mainから機能ブランチを切る

命名規則：feature/issue-123-add-s3-bucket・fix/issue-456-nginx-timeout。issue番号を含めると何の変更か追跡しやすい。

コミットを小さく・頻繁に積む

「1コミット=1つの論理的な変更」を原則にする。大きなコミットはレビューしにくく差し戻しも困難。

Pull Requestを作成してレビューを依頼

PRのDescriptionに「何をしたか・なぜしたか・テスト方法」を必ず記載する。レビュアーへの情報提供が質の高いレビューを生む。

CI通過・レビュー承認後にmainにマージ

GitHub ActionsのCIが全てGREENになりレビュアーのApprovalが得られたらSquash Merge（コミット履歴をきれいにする）してmainにマージ。

コードではなく「動作・ロジック」をレビューする：「なぜこのロジックにしたか」「この条件でエラーにならないか」を確認する
Nitpick（細かい指摘）は明示する：「nit: 変数名をもう少し明確にすると読みやすくなります（必須ではありません）」のように「nitpick」と明示して強制しないことを示す
良い点も褒める：指摘だけでなく「この実装アイデアは良いですね」という肯定的なコメントもチームの雰囲気を良くする

📌 この記事のポイント