Gitを活用したブランチ戦略のメモ

クラウドネイティブで実現する　マイクロサービス開発・運用 実践ガイドという本を読んでいて、ブランチ戦略の説明が非常にわかりやすかったのでメモ。

読んでいた書籍

Git flow

• 大規模開発で定期リリースなどを行っている際に利用される。機能ができたらリリース！というよりも、定期リリースをするような開発チームとかで使われる
• デプロイはdevelopブランチからreleaseブランチを切って、releaseブランチをデプロイ・リリースする
• releaseブランチはリリース後にmainブランチにマージし、マージ後にtagを切る

Git flowで開発をすることはよくあるけれど、いつもmain/masterブランチからデプロイとリリースを行っていたので驚いた。登場するブランチがmain, develop, feature,hotfix, releaseと多岐に渡るので難しいが、大規模開発で本番反映可能なdevelopブランチが一定期間存在するようなケースだと適しているというのは納得？というかそれができるようにflowを組んでいるのか。

Github flow

• mainブランチは何であれデプロイ可能である
• デプロイ自体はmainブランチ以外のfeatureブランチやtopicブランチからも行える
• featureやtopicブランチからもリリースできるということは、それがmainにマージされないまま放置されるとリグレッションが発生するということ

Github flowで開発をすることもよくあるけれど、厳密には大規模向けトランクベースだった。つまりmainしかリリースしないスタイルでやっていた。topicブランチ、という概念は初めて知った。特定トピックについて議論や調査を行うブランチらしい。

GitLab flow

• Github flowに対して、mainブランチを本番にデプロイできないケースを考慮して作られている。そのためにリリース専用のブランチが用意されている。
• リリース専用ブランチには、①プロダクションブランチモデル②環境ブランチモデル③リリースブランチモデルのパターンがある

iOSやAndroidのようにストア審査を通過しないと公開できないケースでproductionブランチをmainブランチから切る、というのは納得度が高い。ストアの審査待ちの間に新しい変更をリリース内容に加えるわけにもいかないので、mainには基本マージしてOK、ストア審査に出すものはproductionブランチで申請する、というのは良さそう。 他のケースはあまりピンときていないけれど、例えばクライアントごとのテナントが存在するケースだと使われそう。mainをすべてのクライアントに適用するのではなく、クライアントごとのリリースブランチがあるイメージ。

トランクベース

• 小規模向け：mainしか存在しない
• 大規模向け：Github flowに加えて、トランク（main）からしかデプロイしないというルールを設ける

これも納得度高い...個人開発だとmainに直pushが基本だからな...なにか懸念があるときくらいしかブランチを切らない。 なんのためにブランチを分けるの？コードレビューをするの？という問いから考えれば、ペアプロ・モブプロによってtrunkベースの開発をすることは何も間違いではない。