🦝

古いバージョンのバグ修正をリリースすることがある場合のGitflowのアレンジ

2024/03/17に公開

古いバージョンのバグ修正をリリースすることがあるプロジェクトの場合でも Git のブランチやタグが複雑にならないように、 Gitflow をアレンジして使っているブランチモデル(aka.ブランチ戦略)についての説明です。

Gitflow について

Vincent Driessen 氏が A successful Git branching model にて公開した Git のブランチモデルのことです。

引用: A successful Git branching model | nvie.com

常に最新のバージョンだけをリリースするプロジェクトであれば Gitflow のブランチモデルで特に問題はないのですが、以下のようなことがある場合、

ver.1.1 を Gitflow のブランチモデルではどう扱うべきなのか、人によって意見が分かれるかと思います。

例えば、

などの方法も考えられるかと思います。

上記の問題を解決するために Gitflow をアレンジしたブランチモデルが以下のものです。

main ブランチから develop ブランチを作成する
develop ブランチから feature ブランチを作成して機能の開発などを進め、完了したら develop ブランチにマージする
develop ブランチから release/1.x ブランチを作成してリリースに必要な作業を進める
release/1.x ブランチでバグが見つかった場合は、 release/1.x ブランチから bugfix ブランチを作成し、修正が完了したら release/1.x ブランチにマージする
リリースに必要な作業、バグ修正の完了後、 release/1.x ブランチにタグを追加してリリースする
リリースの完了後、 release/1.x ブランチを develop ブランチと main ブランチにマージする
新しいバージョンをリリースする場合は、 3～6 と同様の作業を release/2.x のブランチで進める
古いバージョンでバグが見つかった場合は、 4～5 と同様の作業を release/1.x のブランチで進める
古いバージョンのバグ修正のリリース完了後、release/1.x ブランチを release/2.x ブランチにマージする
5～6 と同様の作業を release/2.x ブランチで進める

※ 太字になっている箇所が Gitflow からアレンジした箇所です

標準的な Gitflow ではなく、あくまでも Gitflow のアレンジ版だということに注意してください。