Git運用ルール：master → develop → feature ブランチ戦略のすすめ
チーム開発を行う上で、Gitのブランチ運用ルールはプロジェクトの品質や効率に大きな影響を与えます。
この記事では、「master → develop → feature」というシンプルかつ実践的なブランチ戦略について、その目的と具体的な手順を紹介します。
1. ブランチの役割整理
| ブランチ名 | 役割 |
|---|---|
master |
本番環境に公開する安定版コードを管理 |
develop |
次回リリースに向けた開発統合ブランチ。チームの基盤 |
feature/* |
機能・タスク単位で作成する個別開発用ブランチ |
💡 補足：
実運用では develop_YYYYMMDD や develop_v1.2.0 のように、リリース日の日付やバージョン名を付けたdevelopブランチを使うケースもあります。
これにより、リリースごとの履歴管理や並行開発がしやすくなります。
命名ルールはチームで事前に統一しておきましょう！
2. 運用手順の流れ
ステップ1：develop ブランチを master から作成
git checkout master
git pull origin master
git checkout -b develop
ステップ2：feature ブランチを develop から作成
git checkout develop
git pull origin develop
git checkout -b feature/login-api
開発が終わったら develop にマージ
git checkout develop
git pull origin develop
git merge feature/login-api
git push origin develop
ステップ3：開発が完了したら master へマージ（リリース）
git checkout master
git pull origin master
git merge develop
git tag -a v1.0.0 -m "Release v1.0.0"
git push origin master --tags
3. 運用ルールの補足
-
feature/*ブランチは原則短命。開発が終わったら 削除する -
developブランチでは定期的にmaster をマージして 差分の乖離を減らす -
複数人で作業する場合はPRベースのマージを推奨
→ コードレビュー → テスト確認 → マージ という流れが安全
4. まとめ
この「master → develop → feature」戦略は、Git Flowを簡略化しつつ、
安定性と開発の柔軟性を両立できる実践的な運用方法です。
✅ この運用のメリット
- 本番コード（master）を常に安定化
- 複数人での並行開発がしやすい
- 機能単位でのブランチ管理が明確
チームの規模や開発サイクルに合わせて柔軟に調整しつつ、
シンプルなルールでGit運用を効率化していきましょう 💪