Git FlowとGitHub Flowはパンダとレッサーパンダぐらい違う
至極当たり前のことを言いますが、Gitって便利ですよね。
開発の際にはその恩恵を多大に受けています。
Gitに足を向けて眠れません。どの方角にGitがあるのかは知らないですが。
ところで、みなさんはGitを用いたプロジェクトの運用方法で有名なものが2つ存在するということをご存知ですか？
その名も”Git Flow“と”GitHub Flow“です。
名前も似ていてややこしいです。
ずっと同じ開発に携わっていた方などの中にはGitの運用方法が複数あるということは想像すらしていなかった方もいるのではないかと思います。かく言う自分もそうでした。
今回はGit FlowとGitHub Flowの運用方法を紹介します。
Git Flow
Git Flowはブランチの切り方に特徴があります。
幾つかブランチを用意するんですが、役割を大きく分けるとメインブランチとサポートブランチの二種類が存在し、それぞれ
【メインブランチ】
* masterブランチ
* developブランチ
【サポートブランチ】
* featureブランチ
* releaseブランチ
* hotfixブランチ
というブランチが存在します。それぞれの役割を説明します。
masterブランチ
本番環境と同じ状態に保たれているブランチ。このmasterブランチの変更は本番環境に反映されるので、常に安全でリリース可能な状態にしておかなければならない。
developブランチ
masterブランチから切る。名前の通り開発用のブランチになる。開発が進みリリース完了な状態になったらmasterへとマージさせる。
開発用ブランチとはいえ、このブランチで直接作業したりはしない
featureブランチ
developブランチから切る。機能追加などの作業はこのブランチ上で行う。
目的としていた作業が完了したらdeveopブランチへとマージさせ、このブランチは削除する。作業が生じたらまた新たにdevelopブランチから切ってくる。
releaseブランチ
developブランチから切る。いよいよdevelopブランチをmasterブランチへとマージする前の準備を行う。リリースのためのバグ修正や設定の更新など行い、masterとdevelopへとマージする。
hotfixブランチ
名前の通り、緊急対応のブランチ。masterブランチから切り、バグ等の修正をした後で、masterへとマージさせる。
releaseブランチを経由せずに本番環境へと反映させる。
以上がGit Flowに用いる主なブランチとなります。ブランチの名前が明示的なので役割はわかりやすく運用しやすい反面、フロー自体は少々複雑なものとなっています。
GitHub Flow
一方Github Flowですが、Git Flowほど役割を持ったブランチは必要ありません。
masterブランチ
本番環境と同じ状態に保たれているブランチ。このmasterブランチの変更は本番環境に反映されるので、常に安全でリリース可能な状態にしておかなければならない。
このmasterブランチはGit Flow同様必要です。しかしそれ以外の作業用ブランチは基本的にmasterブランチから直接切ります。
その作業内容がわかりやすいような名前をつけたブランチをmasterブランチから切り、作業が完了したらmasterブランチへとマージさせます。
このとき、勝手にmasterブランチへとマージさせるのではなく、必ずmasterブランチへのPull Requestを作成し、変更点のレビューを仰ぎます。
レビューで何も問題がなかった場合、変更点がmasterブランチへとマージされます。
以上がGitHub Flowとなります。先ほど紹介したGit Flowに比べると用意しなければならないブランチ数も少なく、masterから切ってmasterへとマージするだけなのでフローも単純です。
なので本番環境へと変更を加える回数が多いプロジェクトはGitHub Flow向きかもしれません。
追記
GitHub Flowでは開発者が各々masterブランチへと直接変更を加えようとするのでレビューは必須となります。
このフローが生まれた当時、Pull Requestという機能がGitHubにしか存在しなかったので、名前もそのままGitHub Flowとなりました。
しかし、今やGitlabにもMerge Requestという同様の機能が備わっていますし、GitHub Flowと同様のフローがGitHubの専売特許という訳ではありません(とはいえ同じフローが実現可能というだけで、名前が名前なので一般的にGitHub Flowと呼ばれるものはGitHub上で行われている模様です)。
また、もちろんGit Flowでは変更点のレビューを行わないかというと、当然ですが決してそんなことはなく、上の説明はあくまでも代表的な2つの運用パターンのロールモデルにすぎません。プロジェクトごとに適した派生パターンも勿論存在します。
当然のことながら、これ以外にも「GitLab Flow」と呼ばれる運用方法や、featureブランチを中心に据えた「GitFeature Flow」と呼ばれる運用方法も存在します。
どの運用方法が適しているかというのはケースバイケースですし、恐らくこのフローじゃないと実装できないというような場面も存在しないと思うのですが、とはいえ知らない限り選択することが出来ないのも事実なので、視野は広く持ちたいです。
