【実践】Gitワークフロー完全ガイド - チーム開発で失敗しないブランチ戦略
「ブランチをどう切ればいい？」「mainに直接pushしていいの？」「コミットメッセージに決まりはある？」チーム開発を始めると必ずぶつかるGitワークフローの疑問を、この記事で完全に解消します。
なぜGitワークフローが重要なのか
個人開発ではmainブランチに直接コミットしても問題ありません。しかしチーム開発では、ルールなしにコードを変更し合うと以下の問題が起きます。
- コンフリクトの頻発 - 同じファイルを複数人が同時に変更
- バグの混入 - レビューなしでmainにマージ
- リリース管理の崩壊 - どのコミットが本番に出ているか不明
- 責任の不明確化 - 誰がいつ何を変更したか追えない
ワークフローはこれらを防ぐための「チームの約束事」です。
主要なGitワークフロー3つ
1. Git Flow
最も歴史があり、構造化されたワークフローです。
ブランチ構成:
| ブランチ | 役割 | 寿命 |
|---|---|---|
main | 本番リリース済みのコード | 永続 |
develop | 次回リリースの開発ブランチ | 永続 |
feature/* | 新機能の開発 | 一時的 |
release/* | リリース準備 | 一時的 |
hotfix/* | 本番の緊急修正 | 一時的 |
フロー:
developからfeature/xxxを作成- 機能を実装してPRを出す
- レビュー後に
developにマージ - リリース時は
developからrelease/v1.0を作成 - テスト完了後に
mainとdevelopの両方にマージ mainにタグ付け
向いているケース:
- 明確なリリースサイクルがあるプロジェクト
- モバイルアプリなどバージョン管理が必要
- 大規模チーム（10人以上）
注意点:
- ブランチが多くて複雑になりやすい
- マージ頻度が低いとコンフリクトが大規模になる
2. GitHub Flow
GitHub社が提唱するシンプルなワークフローです。
ブランチ構成:
| ブランチ | 役割 |
|---|---|
main | 常にデプロイ可能な状態 |
feature/xxx | 機能開発・修正 |
フロー:
mainからブランチを作成- コミットを積む
- Pull Requestを作成
- コードレビュー
mainにマージ- 自動デプロイ
# GitHub Flowの典型的な操作
git checkout main
git pull origin main
git checkout -b feature/add-search
# 開発作業...
git add .
git commit -m "feat: add search functionality"
git push origin feature/add-search
# GitHub上でPRを作成 → レビュー → マージ向いているケース:
- 継続的デプロイ（CD）を行うWebアプリ
- 小〜中規模チーム（2〜10人）
- スタートアップなど素早いイテレーションが必要
3. トランクベース開発 (Trunk-Based Development)
Google、Facebookなど大規模テック企業が採用する手法です。
ブランチ構成:
| ブランチ | 役割 |
|---|---|
main（trunk） | 唯一の開発ブランチ |
| 短命ブランチ | 1〜2日で完了する小さな変更 |
フロー:
mainから短命ブランチを作成（またはmainに直接コミット）- 小さな変更を頻繁にマージ（1日1回以上）
- フィーチャーフラグで未完成機能を制御
向いているケース:
- CI/CDが成熟している環境
- 十分なテスト自動化がある
- 高いデプロイ頻度が求められる
ワークフロー比較表
| 項目 | Git Flow | GitHub Flow | トランクベース |
|---|---|---|---|
| 複雑さ | 高 | 低 | 中 |
| ブランチ数 | 多い | 少ない | 最小 |
| マージ頻度 | 低 | 中 | 高 |
| リリース管理 | 厳密 | シンプル | 継続的 |
| 向いている規模 | 大 | 小〜中 | 全て |
| 学習コスト | 高 | 低 | 中 |
迷ったらGitHub Flowを選びましょう。 ほとんどのWebプロジェクトではGitHub Flowで十分です。
Pull Request (PR) のベストプラクティス
PRの粒度
1つのPRは1つの関心事に集中させるのが鉄則です。
- 悪い例: 「ログイン機能の追加 + CSSリファクタリング + バグ修正3件」
- 良い例: 「ログイン機能の追加」のみ
目安:
- 変更行数は400行以下
- レビューに30分以上かかるPRは分割を検討
- 関連しない変更は別PRに分ける
PRテンプレート
チームで統一したPRテンプレートを用意しましょう。
## 概要
<!-- 何を・なぜ変更したか -->
## 変更内容
- [ ] 変更点1
- [ ] 変更点2
## テスト方法
<!-- レビュアーがテストする手順 -->
## スクリーンショット
<!-- UI変更がある場合 -->
## チェックリスト
- [ ] テストを追加/更新した
- [ ] ドキュメントを更新した
- [ ] 破壊的変更はないレビュアーとしてのTips
- コードだけでなく設計を見る - 実装方法だけでなく、アーキテクチャ的に正しいか
- 具体的に指摘する - 「ここはよくない」ではなく「xxxの理由でyyyに変更した方がいい」
- 質問形式を活用 - 「ここはxxxした方が良いのでは？」と提案として伝える
- 良い点も伝える - レビューは批判だけでなく、良いコードを褒めることも重要
コミットメッセージの規約
Conventional Commits
最も広く使われているコミットメッセージの規約です。
<type>(<scope>): <description>
[optional body]
[optional footer]typeの種類:
| type | 用途 |
|---|---|
feat | 新機能 |
fix | バグ修正 |
docs | ドキュメントのみの変更 |
style | コードの意味に影響しない変更（空白、フォーマット等） |
refactor | バグ修正でも機能追加でもないコード変更 |
perf | パフォーマンス改善 |
test | テストの追加・修正 |
chore | ビルドプロセスやツールの変更 |
ci | CI設定の変更 |
例:
# 良い例
git commit -m "feat(auth): add Google OAuth login"
git commit -m "fix(api): handle null response from payment gateway"
git commit -m "docs: update API endpoint documentation"
# 悪い例
git commit -m "fix"
git commit -m "update"
git commit -m "いろいろ修正"なぜコミットメッセージが重要か
- git logが読みやすくなる - 変更履歴が一目で把握できる
- 自動でCHANGELOGが生成できる -
featとfixから自動生成 - セマンティックバージョニングの自動化 -
feat→マイナーバージョンアップ、fix→パッチ
実践: ブランチ命名規則
チーム内でブランチ名のルールを統一しましょう。
feature/ - 新機能開発
bugfix/ - バグ修正
hotfix/ - 緊急修正
refactor/ - リファクタリング
docs/ - ドキュメント命名のコツ:
- 短くても意味がわかる名前にする
- チケット番号を含める:
feature/PROJ-123-add-search - 小文字とハイフンで統一
やってはいけないGitアンチパターン
1. mainへの直接push
# やってはいけない
git push origin mainブランチ保護ルールを設定して、PRなしのpushを禁止しましょう。
2. 巨大なコミット
1コミットで数千行の変更。レビュー不可能で、バグの特定も困難になります。
3. force pushの乱用
# 共有ブランチでは絶対にやってはいけない
git push --force origin develop他の人のコミットが消えます。自分のfeatureブランチ内でのみ使いましょう。
4. コミットメッセージの手抜き
「fix」「update」「wip」だけのメッセージは、3ヶ月後の自分には暗号文です。
まとめ
Gitワークフローは「正解」があるわけではなく、チームの規模・プロジェクトの性質・デプロイ頻度に応じて最適なものを選びます。
初めてのチーム開発なら:
- GitHub Flowを採用
- Conventional Commitsでメッセージを統一
- PRテンプレートを作成
- mainブランチの保護ルールを設定
この4つを実践するだけで、チーム開発の品質が劇的に向上します。
Gitコマンドを素早く確認したい方は、当サイトのGitチートシートも合わせて参考にしてください。