🕌

git feature flowのすゝめ

2025/01/17に公開

git feature flowとはなんぞ

リリーススパンが短い案件がいっぱい並行で動いてるような大規模な現場での構成管理をいい感じにしてくれます(雑
今回は、大元のリポジトリと、そこからforkしたリポジトリを使用して開発することを想定しています。
forkしたブランチを1つ挟むことで、複数人数で同一案件の作業を行う事が多い場合に利便性が高くなります。

git feature flowのブランチ構成

masterブランチ

本番環境にリリースするためのブランチ。
リリース前に最終テストを行ったブランチからマージする。

各テスト環境ごとブランチ

stg、it、testなどなど命名は現場によりけり。

featureブランチ

案件ごとに作成するブランチ。mansterからブランチを切る。
実装担当者はこのブランチに対しプルリクエストを作成し、マージしていく。
テスト環境へデプロイする際は、このfeatureからテスト環境ブランチにマージする。

具体的なフロー一例

■前提
  • リリーススパンは1ヶ月で、毎月なにかの案件でリリースがある。
  • ブランチは下記の分類のものがある。
    • devブランチ:テスト環境リリース用ブランチ
    • stageブランチ:ステージング環境リリース用ブランチ
    • featureブランチ:案件別作業用ブランチ
  • upstreamのリポジトリの、master、stage、devブランチへは、開発者が直接PUSHするのは不可。
  • 各月のdev、stageブランチは、構成管理担当が作成する。
■フロー一覧

①案件の作業開始時には、upstream/masterブランチから、local/feature/case-xxx/yyyy-mmブランチをcheckoutする。

②pull requestを出す先として、upstream/feature/case-xxx/yyyy-mmブランチを作成しておく。

※複数人で同案件作業をする場合で、すでにupstream/feature/case-xxx/yyyy-mmブランチが作られている場合は、①②の作業は不要で、既にあるupstream/feature/case-xxx/yyyy-mmブランチからlocal/feature/case-xxx/yyyy-mmブランチをcheckoutする。

③実装を行い、完了したものをcommitする。

④origin/feature/case-xxx/yyyy-mmブランチへ向けてPUSHする。(初回PUSH時にブランチを作成する)

⑤upstream/feature/case-xxx/yyyy-mmブランチに対して、origin/feature/case-xxx/yyyy-mmブランチからpull requestを作成する。

※テスト環境へのリリースモジュールが出そろうまで(単体テストバグフィックスや追加要件作業など)、③〜⑤を繰り返す。

⑥dev環境へpull requestを出し、マージされたものをリリースする。

⑦テスト環境でのテスト完了後、stage環境へpull requestを出し、マージされたものをリリースする。

※テスト環境、ステージング環境でのテストでバグが発生すれば、再度③〜⑤を繰り返す。

⑧全てのテスト完了後、masterブランチへpull requestを出し作業完了。

補足

リモートリポジトリからワークディレクトリまでの相関図

Discussion