チーム開発の運用フロー - GitHub Flow 完全ガイド

ひとりで開発するときは自由に作業できますが、チームになった途端にルールが必要になります。「誰かの変更で自分のコードが壊れた」「どのブランチが最新か分からない」——こういった問題を防ぐのが、チーム開発の運用フローです。

この記事では、GitHub を使ったチーム開発の標準的な運用方法を解説します。

対象読者: Git と GitHub の基本操作を習得し、チームでの開発を始める方

学習時間の目安: 読了 25分 ＋ 実践 20分

前提知識: ブランチとマージ と GitHub Issues を理解していること

GitHub Flow とは

GitHub Flow（ギットハブ フロー）とは、main ブランチを中心とした、シンプルなブランチ戦略です。 複雑なブランチ管理を避け、迅速なリリースを可能にします。

GitHub Flow の流れ

1. main ブランチから新しいブランチを作る
2. ブランチで変更をコミットする
3. Pull Request を作成する
4. コードレビューを受ける
5. main ブランチにマージする
6. デプロイする

このサイクルを繰り返すだけです。複雑なルールはありません。

Git Flow との違い

もうひとつよく知られているブランチ戦略が Git Flow です。GitHub Flow との主な違いを比較します。

比較項目	GitHub Flow	Git Flow
ブランチ数	main + 作業ブランチ	main / develop / feature / release / hotfix の5種類
複雑さ	シンプル	複雑
リリース頻度	随時（継続的デプロイ向き）	計画的なリリースに向く
向いているプロジェクト	Web サービス・SaaS など	バージョン管理が必要なライブラリ・アプリ

Web サービスの開発には GitHub Flow が適しています。 リリースの計画が複雑でスケジュール管理が必要な場合は Git Flow を検討してください。

---

ブランチ命名規則

ブランチ名は「このブランチで何をするか」が一目で分かるように付けます。 命名規則を統一することで、チーム全員が状況を把握しやすくなります。

よく使われるプレフィックス

プレフィックス	用途	例
feature/	新機能の開発	feature/user-authentication
fix/	バグ修正	fix/login-button-not-responding
hotfix/	本番環境の緊急修正	hotfix/payment-error
chore/	テスト・設定・ライブラリ更新など	chore/update-dependencies
docs/	ドキュメントの更新	docs/api-reference
refactor/	リファクタリング（機能変更なし）	refactor/auth-module

良い命名例・悪い命名例

評価	例	理由
良い	feature/add-search-function	何をするか明確
良い	fix/issue-42-null-pointer	Issue 番号付きで追跡しやすい
悪い	test	内容が不明
悪い	yamada-branch	人名では内容が分からない
悪い	fix	何を修正するか不明
悪い	新機能追加	日本語や空白はトラブルの原因になる

ブランチ名には 英小文字・数字・ハイフン を使い、スペースや日本語は避けてください。

---

コミットメッセージの規約

コミットメッセージはコードの変更履歴です。 「何を変えたか」だけでなく「なぜ変えたか」が伝わるメッセージを書くことが重要です。

Conventional Commits

Conventional Commits（コンベンショナル コミッツ）とは、コミットメッセージのフォーマットを統一するための仕様です。

フォーマット: <type>(<scope>): <説明>

タイプ	意味	例
feat	新機能の追加	feat: ユーザー検索機能を追加
fix	バグ修正	fix: ログインボタンが押せない問題を修正
docs	ドキュメントの変更	docs: READMEにセットアップ手順を追加
style	コードのフォーマット変更（動作変更なし）	style: インデントを修正
refactor	リファクタリング（機能変更なし）	refactor: 認証ロジックを関数に分割
test	テストの追加・修正	test: ログイン機能のユニットテストを追加
chore	ビルド設定・依存ライブラリ更新	chore: eslint を v8 にアップデート
ci	CI 設定の変更	ci: GitHub Actions のワークフローを修正

良いコミットメッセージの書き方

# 良い例
feat(auth): パスワードリセット機能を追加

ユーザーがパスワードを忘れた場合に、メールアドレスで
リセットリンクを送信できるようにした。

Closes #78

# 悪い例
修正
update
asdfghjkl

コミットの粒度

1 つのコミットには 1 つの変更だけを含めます。 「ログイン機能の追加」と「ヘッダーのデザイン変更」を同一コミットにまとめると、後で問題を追跡するときに困ります。

---

Pull Request のベストプラクティス

PR のサイズを小さく保つ

PR は小さければ小さいほど良いです。 大きすぎる PR はレビュアーの負担になり、レビューの質が下がります。

PR のサイズ	変更行数の目安	レビューしやすさ
小（理想）	〜200行	集中してレビューできる
中（許容範囲）	200〜400行	丁寧に読めばレビューできる
大（要注意）	400行以上	レビュアーへの負担が大きい

PR の説明の書き方テンプレート

## 変更内容
- ユーザー検索機能を追加した
- 検索結果を一覧表示するコンポーネントを追加した

## 変更の理由
Issue #42 のユーザーリクエストに対応するため。
ユーザーが他のユーザーを名前で検索できる機能が不足していた。

## テスト方法
1. アプリを起動する
2. ヘッダーの検索バーに名前を入力する
3. 検索結果が表示されることを確認する

## スクリーンショット
（変更前）（変更後）

## 関連 Issue
Closes #42

セルフレビューの重要性

PR を出す前に、まず自分でレビューする習慣をつけてください。 GitHub の「Files changed」タブでコードの差分を眺めると、タイプミスや不要なデバッグコードに気づくことがあります。

---

コードレビューの文化

コードレビューの目的は「コードの品質向上」と「チーム全員での知識共有」です。 犯人探しではありません。

レビューコメントの書き方

種別	書き方	例
必須修正	[must] や「〜してください」	[must] SQL インジェクションの脆弱性があります
提案	[nit] や「〜はどうでしょう」	[nit] この変数名、もう少し具体的にするとより読みやすいかもしれません
質問	「〜は何のためですか？」	この条件分岐はどのケースを想定していますか？
褒める	「良いですね」「参考になります」	このアプローチはシンプルで良いですね！

Approve / Request Changes の使い分け

アクション	意味	いつ使うか
Comment	コメントのみ	質問や提案があるが、マージをブロックしない
Approve	承認	このまま（または軽微な修正後）マージしてよい
Request changes	変更を要求	マージ前に必ず修正が必要

レビュワーとしての心得

• コードを批判するのであって、人を批判しない
• 「なぜ悪いか」の理由を説明する
• 良いコードも積極的に褒める
• 24時間以内にレビューするよう努める

レビューを受ける側の心得

• レビューコメントを個人攻撃と受け取らない
• 「修正しました」と返信して変更を伝える
• 意見が合わない場合は議論してよい
• Approve が来たらマージしてよい

---

ブランチ保護ルール（Branch Protection Rules）

ブランチ保護ルールとは、main ブランチへの誤った変更を防ぐための設定です。 「レビューなしでマージできない」「テストが失敗したらマージできない」といったルールを自動的に強制できます。

設定方法

「Settings」→「Branches」→「Add branch protection rule」から設定します。「Branch name pattern」に main と入力して、以下のルールを設定します。

代表的な設定

設定項目	説明	推奨
Require a pull request before merging	マージには PR が必要	有効化
Required number of approvals	必要な Approve 数	最低 1
Dismiss stale pull request approvals when new commits are pushed	新しいコミットが追加されると Approve がリセットされる	有効化
Require status checks to pass before merging	CI のテストパスが必要	有効化
Require branches to be up to date before merging	マージ前にブランチが最新であることを要求	有効化
Do not allow bypassing the above settings	管理者もルールを迂回できない	有効化を検討
Allow force pushes	強制プッシュを許可	無効化

---

CODEOWNERS の設定

CODEOWNERS（コードオーナーズ）とは、特定のファイルやディレクトリが変更されたとき、そのファイルに詳しい人が自動的にレビュワーとして割り当てられる仕組みです。

.github/CODEOWNERS の書き方

# 書式: <パターン> <GitHubユーザー名またはチーム名>

# すべてのファイルの変更に @alice を割り当て
* @alice

# frontend/ 配下の変更は @bob と @carol
frontend/ @bob @carol

# バックエンドのコアロジックは @backend-team が担当
src/core/ @myorg/backend-team

# ドキュメントの変更は @docs-team
*.md @myorg/docs-team

# セキュリティ関連のファイルは @security-team が必ずレビュー
.github/workflows/ @myorg/security-team

CODEOWNERS を設定すると、ブランチ保護ルールの「Require review from Code Owners」と組み合わせて、重要なファイルが必ず担当者にレビューされるようになります。

---

マージ戦略の選択

PR をマージするとき、GitHub では 3 つの方法が選べます。チームで統一しておくと、履歴が読みやすくなります。

マージ方法	特徴	向いている場面
Merge commit	すべてのコミットが保持され、マージコミットが作成される	変更の経緯をすべて残したい場合
Squash and merge	ブランチのすべてのコミットを 1 つにまとめてマージ	コミット履歴をスッキリさせたい場合
Rebase and merge	マージコミットを作らずに直線的な履歴にする	main の履歴を直線的に保ちたい場合

初心者チームには「Squash and merge」がおすすめです。 作業中の細かいコミット（「修正」「WIP」など）が main に残らず、履歴が読みやすくなります。

---

リリース管理

マイルストーンの活用

マイルストーン（Milestone）とは、特定のリリースや期限に向けて Issue や PR をグループ化する機能です。

「Issues」→「Milestones」→「New milestone」から作成します。目標日とマイルストーン名（例: v1.0.0 リリース）を設定し、関連する Issue をマイルストーンに紐づけます。

進捗がパーセンテージで表示されるため、リリースまでの残り作業量が一目で分かります。

リリースノートの書き方

良いリリースノートには以下の情報を含めます。

## v1.2.0 (2026-03-21)

### 新機能
- ユーザー検索機能を追加 (#42)
- ダークモード対応 (#55)

### バグ修正
- ログインボタンが特定の環境で押せない問題を修正 (#61)
- プロフィール画像が正しく表示されない問題を修正 (#63)

### 変更点
- Node.js の対応バージョンを v18 以上に変更

---

チーム開発のアンチパターン

以下は、チーム開発でやってはいけないことです。

main への直接 push

# やってはいけない
git push origin main

main への直接 push は禁止です。 ブランチを作り、PR を通じてマージしてください。ブランチ保護ルールを設定すると、物理的に防ぐことができます。

大きすぎる PR

1,000 行を超える PR はレビュアーが実質的にレビューできません。機能ごとに PR を分割してください。

レビューなしのマージ

「急ぐから」という理由でレビューをスキップするのは危険です。本番障害の多くはレビューなしの変更から発生します。

コンフリクトを放置したまま PR を出す

PR を出す前に main ブランチの変更を取り込み、コンフリクトを解消してください。

意味のないコミットメッセージ

「修正」「update」「asdf」のようなメッセージは、後で何を変えたのか分からなくなります。

フォースプッシュを共有ブランチで使う

git push --force は共有ブランチでは使わないでください。他の人のコミットを上書きする危険があります。どうしても必要な場合は --force-with-lease を使い、チームに事前に連絡してください。

---

FAQ

Q. GitHub Flow と Git Flow はどちらを選べばよいですか？

多くの Web サービス開発では GitHub Flow を推奨します。 Git Flow は管理するブランチが多く学習コストが高いため、まずは GitHub Flow から始めることをおすすめします。複数バージョンを同時メンテナンスする必要がある場合に Git Flow を検討してください。

Q. コミットメッセージは日本語でよいですか？

チームの合意があれば日本語でも問題ありません。 ただし、オープンソースプロジェクトや国際チームでは英語が標準です。Conventional Commits の形式（feat:, fix: など）は言語に関わらず採用できます。

Q. PR のレビューで意見が対立した場合はどうすればよいですか？

まずはテキストで議論し、解決しない場合は口頭や会議で話し合ってください。 レビュー上の議論は個人の感情を排除し、コードの品質向上という共通目標に向けて進めることが重要です。

Q. ブランチ保護ルールを設定したら誰もマージできなくなりました。

「Do not allow bypassing the above settings」が有効で、必要な Approve 数を満たしていない場合にマージできなくなります。 必要な Approve 数を「1」に設定し、自分以外のメンバーに Approve してもらうとマージできます。チームが 1 人の場合は、Approve 数を「0」に設定するか、ブランチ保護を調整してください。

Q. Squash and merge を使うとコミット履歴が消えますか？

元のブランチは削除しない限り残っています。 main の履歴からは見えなくなりますが、元のブランチや PR のページから個々のコミットを確認できます。