git-flowモデルについてまとめ
概要
git flow モデルを参考に、社内の開発チームで設定したいブランチモデル及び、ブランチ命名規則を記載する。
git flowについては以下を参照
開発チーム内でブランチの名前の付け方をできる限り統一したい。
ブランチ名の頭につけるフレーズ(\ バックスラッシュより前の部分)について
ブランチ名の頭に以下のフレーズをつけて、
そのブランチで行われている開発や修正が、どういった属性のものなのかを大きなくくりで分かるようにする。
master
→ 本番環境にリリースしている最新の状態
→本番環境にリリースする際に、バージョン番号をタグ付けして管理をする。
→CDを導入しているプロジェクトでは、developブランチがmasterにマージされた時点で、masterブランチが本番環境に自動でリリースされる。
※特定のコミットに対してタグ付けをする参考資料
develop
→masterからdevelopを切る。
→ステージング環境に置いておく、masterにマージする前に、developブランチに改修や機能追加をためておいて、区切りのついた時点で、バージョン番号をタグ付けしてmasterにマージする。
→また、本番環境にリリースする前に、お客さんに確認してもらったり、社内の担当者に確認をしてもらうためのブランチという意味合いもある。
→CDを導入しているプロジェクトでは、各開発ブランチがdevelopにマージされた時点で、developブランチがステージング環境に自動で反映される。
feature
→master OR developからfeatureを切る。様々な機能開発を行うブランチ。
→ex: feature/dataHighlight
fix
→master OR developからfixを切る。様々な改修や、バグ修正を行うブランチ。
→ex: fix/topPage-table
release
→master OR developから切る。リリースの際に複数の関連する作業がある場合にそれらを統合するためのブランチ。
リリースした後、このブランチは削除。
→ex: release/3c-manager
hotfix
→masterから切る。重大なバグに対して、緊急の対応を行う場合に、作成するブランチ。
→ex: hotfix/dataHighlight-cantShow
ブランチ名の後半につけるフレーズ(\ バックスラッシュより後の部分)について
→ブランチ名の中で、意味の区切りとなる所は - ハイフンで区切る。
→スネークケース( hightlight_data みたいな感じで区切りを -
ハイフンにするやつ)を使う
CI/CDパイプラインと組み合わせた際の運用フロー
参考サイト
Discussion