Gitflow とは
目次
概要
git を個人やチームで使用すると、何かしらの ブランチ戦略を使うかと思います。
本記事では git ブランチ戦略のうちの一つ、Gitflow について紹介します。
Gitflow とは
Gitflow をできるだけ短く説明すると：
- develop ブランチを主体に開発を行い、ある程度溜まったら main に向けてマージする手法です。
Vincent Driessen が提唱した運用方法だそうです。
以下、Gitflow の運用を示した図です。
図：https://nvie.com/img/git-model@2x.png より
よくこの図を見かけるかもしれませんが、初見だと混乱するかもしれません。
しかし、git 使用時のシナリオを一個ずつ説明していけば上記の意味は理解できるかと思います。
ここで、主体となるブランチと、それぞれのシナリオごとでの流れについて説明します。
主ブランチ
まず主体となるブランチについてです。
Gitflow では main と develop が主体のブランチとなります。
develop は開発途中の記録する開発ブランチで、main は外部のユーザーに見せる本番ブランチです。
多くの開発現場ではこの main ブランチを本番環境と同期させることがあります。
そのため、開発途中のものを別のブランチで管理する必要があります。
develop がそれに相当します。
運用方法として、チームで開発するときには編集履歴を develop ブランチにマージして、ある程度ユーザーに見せれる状態だと判断したときに main ブランチにリリースすると言うイメージです。
ただし、直接 develop を main にマージするのではなく、release というブランチを介してリリースします。（後に解説）
main にマージしたら、main から派生するのではなく、引き続き develop で継続的に変更履歴を追加します。
では、実際にこれらを主体とした時にどのように機能追加、リリース、Hot Fix の際にどのように運用するか見ていきましょう。
機能追加
機能追加するときの流れについてです。
機能追加するときには develop ブランチから feature ブランチを派生します。 機能開発するときに十分要件を満たしていると判断したときに develop ブランチにマージします。 修正、リファクタリングも同様に develop ブランチから派生します。
リリース
続いてリリースするときの流れについてです。
develop ブランチがある程度ユーザーに見せれる状態だと判断したときに main ブランチへのリリース準備をします。 release ブランチは develop ブランチから派生をさせ、QA を行います。大丈夫だと判断とした場合に、release ブランチを main にマージします。
Hot Fix
続いて Hot Fix するときの流れについてです。Hot Fix は緊急時の対応を要する fix のことを指します。
何かしらのエラーが main で見つかった場合に main から fix ブランチを派生します。
修正し、大丈夫と判断したら、main, develop にマージします。
まとめ
以上が Gitflow についてでした。 今後とも、参考にしていただけたらと思います。
