Git flow (A Successful Git Branch Model) には
feature ブランチごとの制作の速度や規模に差がある場合、
リリースのフェーズになかなか入れない欠点がありました。
ここで紹介する拡張 Git flow は、
制作の速度や規模にばらつきがある場合でも
完成した feature ブランチからリリースの準備に入ることができるように
ブランチの分け方とマージの方法を変更したブランチモデルです。
概要
Git flow の問題点を解決するため 筆者が Git flow を独自に拡張した方式で
4年以上の運用実績があります。
また、ぐるなびさんが Git Feature flow と命名して
ほぼ同様のブランチの分け方を採用しているようで、
テストを厳密に行い、ブランチごとの編集の速度や規模に差がある場合、
このブランチの分け方に行き着くものと思われます。
向いている制作
- 夜間の自動テストなどを利用して
複数の製作者の編集内容をまとめて確認することで
制作物の公開前の確認工程にかかる時間的・金銭的コストを
圧縮できる場合 - 各 feature ブランチの製作速度に大きな差がある場合
長所
- 夜間の自動テストで多数の feature ブランチの確認を一度に実施できます
- すべての feature ブランチがいつでも夜間の自動テストを利用できます
- 各 feature ブランチの製作速度に大きな差があっても
完成した feature ブランチからリリース準備に入ることができます
短所
- feature ブランチを develop ブランチと release ブランチに
1 回ずつマージする必要があります
ブランチと役割
拡張 Git flow では 5 種類のブランチを用います。
- 恒常的に存在するブランチ
- master ブランチ
- develop ブランチ
- release ブランチ
- 一時的に作成されるブランチ
- feature ブランチ
- hot-fix ブランチ
これらのブランチの役割自体は Git flow と変わりません。
Git flow との違い
Git flow との違いは、ブランチの作成元とマージ先です。
master ブランチから release ブランチを作成
Git flow では develop ブランチから release ブランチを作成しましたが、
拡張 Git flow では 最初に master ブランチから release ブランチを作成し、
その後、develop ブランチと同様に維持し続けます。
master ブランチから feature ブランチを作成
develop ブランチから feature ブランチを作成すると
他の feature ブランチの制作内容を含んでしまいますが
master ブランチから作成することにより、
各 feature ブランチの制作内容がお互いの制作内容を含まなくなります。
feature ブランチを release ブランチにマージ
develop ブランチで、夜間に実行される自動テスト等で
各 feature ブランチの完成度を確認し、
完成した feature ブランチから順に release ブランチにマージしていきます。
develop ブランチからはどこにもマージしない
develop ブランチは自動テストを実行するためだけのブランチで
不具合が含まれている可能性が高いため、
ここから feature ブランチを作成したり
他のブランチにマージしてはいけません。
このブランチモデルが必要になった経緯
筆者はシステムの安定性が重視される Web サービスを開発しており、
Selenium という、ブラウザーの操作をプログラミングする方法で
自動的なテストを実施していました。
このテストを行うためのインフラ環境構築と、テストの実行には
大きなコストがかかるため、
GitHub flow で開発を行うことはできませんでした。
(GitHub flow は各 feature ブランチごとにテストを実施するためです。)
また、開発チームには週 2 ～ 3 日だけ開発に参加する
アルバイトの学生もいましたが、
Git flow での開発では
develop ブランチから release ブランチを作成するために
彼らのブランチの完成を待つ必要がありました。
develop ブランチでの自動テストの集約を維持したまま、
完成したブランチからリリースできる仕組みを検討した結果、
このブランチモデルで開発を行っています。
