Git 運用 ブランチ運用ワークフロー

はじめに

前回の「Git 運用 PRのワークフロー。PRレビューは"PRの記載粒度"が重要！」に続き、Git 運用についてまとめです。
今回は ブランチのワークフローをまとめます。

WIPのブランチもあると便利と、最近体感しました。

主要ブランチ

メインブランチ

• main:
  • リリース可能な状態を維持
  • 本番環境へのデプロイに使用

環境別ブランチ

• develop:
  • 開発作業のマージ先ブランチ
  • 開発環境へのデプロイに使用
• staging:
  • develop からマージ
  • 検証環境へのデプロイに使用
• prod:
  • staging からマージ
  • 本番環境へのデプロイに使用
  • mainの代替。main を本番用に使用する場合はこのブランチを使用しない

作業用ブランチ

• 命名規則:

  • 英小文字のみ使用
  • 単語はハイフン(-)で区切る
  • Issue番号を含める

• feature/#<Issue番号>-<説明>: 機能開発ブランチ

  # 例
  feature/#7-add-user-authentication
  

  • 対象:
    • 新機能開発
    • ドキュメント修正
    • ユニットテスト追加
    • フォルダ構成変更
    • バッグ対応以外の修正

• bugfix/#<Issue番号>-<説明>: バグ修正ブランチ。

  # 例
  bugfix/#12-fix-login-error
  

  • 対象:
    • 不具合対応

• release/<バージョン番号>: リリース準備のためのブランチ。

  # 例
  release/v1.2.3
  

一時的な作業用ブランチ

• wip/<name>-<short-description>: 一時的な作業のためのブランチ
  • 使用目的
    • ブランチのプッシュのテスト
    • 個人での一時的な検証や修正作業
  • 運用ルール
    • <name> でブランチの作成者の名前を記入する。このブランチは作成者のみ使用する
    • このブランチからは PR を作成しない
    • 作業完了後速やかに削除する
  • 注意点
    • ブランチを整理時に、これらのブランチは削除対象となる

ブランチ運用ルール

1. 開発の流れ:

   feature/bugfix → develop → staging → prod(main)
   

2. レビュー要件:

   • feature/bugfix ブランチはPRを通して develop にマージ
   • develop から staging へは検証後にマージ
   • staging から prod(main) へは承認後にマージ

3. 命名時の注意点:

   • 分かりやすい説明を心がける
   • 一貫性のある命名規則を守る
   • Issue番号は必ず含める

ブランチ削除ポリシー

• feature/bugfix ブランチ: マージ後に削除
• release ブランチ: リリースのタグ付けが完了した後に削除
• 環境ブランチ（develop/staging/prod）: 永続的に保持

おわりに

このブランチを運用するまでは、WIP ブランチは作ったことが無かったのですが、結構便利ですね。
WIPとつけると削除しやすい（意味的にも、コマンド的にも）です。
今のところ作業ブランチを最小種類にしてますが、コミットと同様に５種類ぐらいまでは増やしてもいいかもしれませんね。

---