会社で Git Flow を運用し始めてから 3 か月以上が経ちました。チームの拡大、要件とユーザーの増加に伴って、バージョン管理フローがどう変遷してきたかを記録しておきます。
このようなフローは、安定的かつ継続的なデリバリーに役立ちます。
# 1 本のメインブランチ
master
- チームリードの個人プロジェクトで、ユーザーもほとんどいなかったため、
masterは私の遊び場でした。好きなように変更し、壊しても誰かに気づかれる前に元に戻せばよい、という感じでした。
# 2 本のメインブランチ
masterdevelop
- 業務要件が増え、初期メンバーが加わりました。
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 を使わない理由はありますか？ ぜひ下のコメントで共有してください。