私が理解している GitFlow

会社で Git Flow を運用し始めてから 3 か月以上が経ちました。チームの拡大、要件とユーザーの増加に伴って、バージョン管理フローがどう変遷してきたかを記録しておきます。

このようなフローは、安定的かつ継続的なデリバリーに役立ちます。

# 1 本のメインブランチ

master

チームリードの個人プロジェクトで、ユーザーもほとんどいなかったため、master は私の遊び場でした。好きなように変更し、壊しても誰かに気づかれる前に元に戻せばよい、という感じでした。

# 2 本のメインブランチ

master

develop

業務要件が増え、初期メンバーが加わりました。develop と master にブランチを分け始め、メンバーは直接 develop で開発します。develop と master はそれぞれテスト環境と本番環境の CI/CD に紐付け、develop はテスト用、master はデリバリー用とし、開発サイクルごとに develop を master へ一度マージして新バージョンとしてリリースします。

# 2 本のメインブランチ、1 本のサブブランチ

master（メイン）

develop（メイン）

feature（サブ）

コード品質を確保するため、要件を実装する際は全員が develop から feature ブランチを切り、develop へマージし戻すたびに Pull Request を発行し、チームリードがレビューしてマージします。

自分のコードをレビューしやすくするため、開発の過程でリファクタリングが必要な場合は、リファクタリング用の feature ブランチを別途切ってコードをリファクタリングし、新機能はそのリファクタリングブランチをベースに開発を続けます。1 つの機能を複数の PR に分割でき、各 PR で変更するファイル数をできるだけ減らします。

要件が終わらず、メンバーがさらに増えました。チーム内の交流を促進し同期を保つため、プロジェクトの拡大に伴い、PR を出す際に関連メンバー（このコードに触れたことがある人、またはこれから触れる人）に Assign できるようにしました。チームの中心は分散し、全員がお互いのコードにコメントし Approved できます。

コーディングスタイルを揃えるため、一定の周期ごとにその周期で出された PR をレビューし、コーディングスタイルをドキュメント化して、将来入社する人がプロジェクトを素早く理解しチームに溶け込めるようにします。

# 2 本のメインブランチ、2 本のサブブランチ

master（メイン）

release（サブ）

develop（メイン）

feature（サブ）

develop をテスト環境としていましたが、多人数での協働では、未完成のコードがうっかり develop にマージされると、テスト担当者の QA に影響します。そこで release ブランチを追加して develop のテスト機能を代替し、元のテスト環境の CI/CD を develop から release へ付け替えました。こうすると PR を develop にマージしてもデプロイされず、不要なビルド時間を減らせるだけでなく、release ブランチで問題が起きたときには、release を develop 上の問題のないコミットへ即座に rebase して QA のテストに影響が出ないようにできます。テストで問題に遭遇した場合も release 上ですぐに修正でき、ただし最後にメインの develop ブランチへマージし戻すことを忘れないようにします。

# 2 本のメインブランチ、3 本のサブブランチ（GitFlow）

master（メイン）

hotfix（サブ）

release（サブ）

develop（メイン）

feature（サブ）

このフローを経ても、本番環境にバグがデプロイされてしまうことはあります。そのときは master から hotfix ブランチを切って緊急対応し、問題ないことを確認したら、master と develop の 2 つの主要ブランチへマージし戻します。hotfix を develop にマージしないと、次の周期のデプロイ時に修正した hotfix が上書きされてしまう可能性が高いです。

Git Flow を使わない理由はありますか？ ぜひ下のコメントで共有してください。