ブランチの分け方にはいくつかの推奨されている方法があります。
ここでは 1 つの中央リポジトリーを中心とした制作で
主に推奨されているブランチの分け方を紹介します。
各方法ごとに向いている制作を挙げていますので、
制作内容によって使い分けることをおすすめします。
Linux 知識の要らない Git 講座 目次にもどる
GitHub flow
GitHub が推奨しているブランチの分け方です。
↓公式のドキュメントはこちらです。
Understanding the GitHub flow · GitHub Guides
ブランチの分け方だけでなく、
編集内容の確認プロセスまで定義されているのが特徴です。
向いている制作
- 制作物の公開前の確認に時間的・金銭的コストがかからない場合
- 制作物の公開前の確認の時間的・金銭的コストを解決できる場合
- feature ブランチを一度に複数作らない場合
長所
- 他の方式よりもブランチの分け方がシンプルです
短所
- 編集内容の確認を feature ブランチごとに行うため、
確認に時間的・金銭的コストがかかる場合、向きません
Git flow (A Successful Git Branch Model)
GitPrime 社の元 CTO の Vincent Driessen さんが
2010 年に自身のブログで発表した 「A Successful Git Branch Model」で
推奨されているブランチの分け方です。
夜間に自動的にテストを行う必要があるほどに
大規模であったり、もしくは品質を重視したプログラム開発を
想定した方法です。
また、ブランチの分け方だけでなく
プログラムのバージョンの決め方についても述べられています。
向いている制作
- 夜間の自動テストなどを利用して
複数の製作者の編集内容をまとめて確認することで
制作物の公開前の確認工程にかかる時間的・金銭的コストを
圧縮できる場合 - 各 feature ブランチの製作速度に大きな差がない場合
長所
- 夜間の自動テストで多数の feature ブランチの確認を一度に実施できます
短所
- feature ブランチごとの製作速度や規模に差があっても、
最も制作の遅い feature ブランチの完成を待たないと
先に完成した feature ブランチをリリースできません - 先にリリースするべき feature ブランチが完成するまで
その次にリリースする予定の feature ブランチは
夜間の自動テストを利用できません - 共同制作者が増えると全ての feature ブランチがテストを通過することが減っていき、リリースのフェーズに入るのが難しくなります
拡張 Git flow (Git Feature flow)
Git flow の問題点を解決するため 筆者が Git flow を独自に拡張した方式で
4年以上の運用実績があります。
また、ぐるなびさんが Git Feature flow と命名して
ほぼ同様のブランチの分け方を採用しているようで、
テストを厳密に行い、ブランチごとの制作の速度や規模に差がある場合、
このブランチの分け方に行き着くものと思われます。
↓詳しくはこちらの記事ご覧ください。
拡張 Git flow (Git Feature flow)
向いている制作
- 夜間の自動テストなどを利用して
複数の製作者の編集内容をまとめて確認することで
制作物の公開前の確認工程にかかる時間的・金銭的コストを
圧縮できる場合 - 各 feature ブランチの製作速度に大きな差がある場合
長所
- 夜間の自動テストで多数の feature ブランチの確認を一度に実施できます
- すべての feature ブランチがいつでも夜間の自動テストを利用できます
- 各 feature ブランチの製作速度に大きな差があっても
完成した feature ブランチからリリース準備に入ることができます
短所
- feature ブランチを develop ブランチと release ブランチに
1 回ずつマージする必要があります
