チーム開発では、Gitのコマンドを覚えるだけでなく、ブランチをどのように運用するかが非常に重要です。
運用ルールが曖昧だと、
- どこで作業すればいいか分からない
- 誤って本番ブランチへpushしてしまう
- コンフリクトが増える
- レビューしづらい
といった問題が発生しやすくなります。
今回は、実務でよく使われる Gitブランチ運用ルール を分かりやすくまとめます。
※現場で指定されたルールがある場合は、そちらのルールを守ること
ブランチの基本構成
実務では、以下のような構成で運用することが多いです。
main
└ develop
├ feature/login
├ feature/user-list
├ fix/header-style
└ hotfix/login-error
1. main ブランチ
main は 本番環境にリリースされるコード を管理するブランチです。
役割
- 本番リリース用
- 安定版コード
- 直接作業しない
実務ポイント
基本的に 直接commit / push はしません。
Pull Request経由でのみマージする運用が一般的です。
2. develop ブランチ
develop は 開発中のコードを集約するブランチ です。
役割
- 開発用の統合ブランチ
- featureブランチのマージ先
- テスト環境反映用
実務ポイント
日々の開発作業は、ここからブランチを切ることが多いです。
git checkout develop
git pull
3. feature ブランチ
新機能追加時に使用します。
git checkout -b feature/login-function
用途
- 新規画面作成
- API追加
- UI改修
- バッチ処理追加
命名ルール例
feature/loginfeature/user-listfeature/export-csv
実務ポイント
1機能 = 1ブランチ
にするとレビューしやすくなります。
4. fix ブランチ
軽微な修正やバグ対応で使用します。
git checkout -b fix/header-style
用途
- 表示崩れ修正
- バリデーション修正
- 文言修正
実務ポイント
小さな修正でもfeatureと分けることで、目的が明確になります。
5. hotfix ブランチ
本番障害など緊急対応用です。
git checkout -b hotfix/login-error
用途
- 本番バグ修正
- 緊急リリース
- 障害対応
実務ポイント
緊急対応時は main から直接切るケースもあります。
git checkout main
git checkout -b hotfix/login-error
ブランチ運用の基本フロー
普段の流れは以下のようになります。
git checkout develop
git pull
git checkout -b feature/user-list
作業後
git add .
git commit -m "ユーザー一覧画面を追加"
git push origin feature/user-list
その後、Pull Requestを作成して develop へマージします。
運用ルールで意識したいこと
1. mainで直接作業しない
これは最重要です。
誤って本番コードを壊すリスクがあります。
2. ブランチ名を分かりやすくする
悪い例
test
sample
fix1
良い例
feature/login
fix/header-style
hotfix/api-error
3. 長期間ブランチを放置しない
長く放置するとコンフリクトが増えます。
できるだけ小さく区切って早めにマージしましょう。
まとめ
実務では以下のルールを覚えておくとスムーズです。
-
main：本番用 -
develop：開発統合用 -
feature：新機能 -
fix：軽微修正 -
hotfix：緊急対応
ブランチ運用ルールを決めておくことで、チーム開発の効率が大きく上がります。
もし、現場にルールがない場合でもこれらの基本的なルールを守っていると運用がスムーズに行えます。