GitHubを使ったチーム開発では、ブランチ戦略とプルリクエスト（PR）を中心とした運用を整えることで、コード品質を保ちつつ効率よく共同作業が進められます。
本記事では、developブランチを取り入れた基本的な開発フローを紹介します。プロジェクトが大きくなっても破綻しにくい、再利用しやすい構成です。
1. ブランチ構成の方針
| ブランチ名 | 用途 |
|---|---|
main | 本番にリリース済みのコード。常に安定した状態を維持 |
develop | 日々の開発の集約先。レビュー済みのコードのみをマージ |
feature/* | 新機能や修正作業用の一時的なブランチ（develop から分岐） |
hotfix/* | 本番のバグ対応（main から分岐し、mainとdevelopの両方にマージ） |
2. 基本的な開発フロー
① develop ブランチを最新に
git checkout develop
git pull origin develop② 新しい作業ブランチを作成（命名規則は feature/〜）
git checkout -b feature/add-login③ 作業を進め、こまめにコミット
git add .
git commit -m "Add login form layout"④ GitHubへプッシュ
git push -u origin feature/add-login⑤ GitHub上でプルリクエスト作成
- マージ先を
developに指定 - 説明欄に「背景・対応内容・動作確認手順」などを明記
- レビュアーをアサイン
3. プルリクエストのレビューとマージ
- レビュアーが内容を確認・コメント
- 問題なければ
Squash and mergeまたはRebase and mergeを推奨（履歴が整理されるため）
4. マージ後のブランチ削除
マージ済みの feature/* ブランチは削除して問題ありません。
# ローカルから削除
git branch -d feature/add-login
# リモートから削除
git push origin --delete feature/add-loginブランチを残しすぎると管理が煩雑になるため、マージ後は削除する運用を標準化するのがおすすめです。
5. リリース（develop → main）
開発が一定落ち着いたタイミングで、develop を main にマージします。
git checkout main
git pull origin main
git merge develop
git push origin main必要に応じてタグをつけておくと、リリースの区切りが明確になります。
git tag v1.2.0
git push origin v1.2.06. バグ対応（hotfixブランチ）
本番環境に即時対応が必要なバグは main から hotfix/* ブランチを切って対応します。
git checkout main
git pull origin main
git checkout -b hotfix/fix-header-bug
# 修正後
git add .
git commit -m "Fix header display bug"
git push origin hotfix/fix-header-bugプルリクでは main と develop の両方にマージすることで、修正が両方のブランチに反映されます。
補足：ブランチ命名規則の一例
| 用途 | 接頭辞 | 例 |
|---|---|---|
| 新機能追加 | feature/ | feature/add-login |
| バグ修正 | fix/ | fix/input-validation |
| 急ぎ修正 | hotfix/ | hotfix/production-crash |
| 試験・検証 | test/ | test/api-endpoint |
まとめ
develop ブランチを軸としたブランチ運用は、以下のようなメリットがあります。
- 本番環境（
main）を常に安定させられる - 複数人が同時に安全に開発可能
- プルリクエスト単位でレビューがしやすい
- チームごとの役割分担がしやすい
コメント