GITブランチモデルを見直した

最初にまとめ

• 10年間git flowモデルでやってきたのを見直した
• 結局git flowベースの独自ルールになった
• 現在ではgit flowは良しとされていないが、新しいベストプラクティスがあるわけでもないため、既存のルールが合わなければ自分で独自ルールを決める必要がある

きっかけ

今まで業務ではほぼBitBucketを使用して開発していたが、
同じチームのまま追加で開発することになった新規サービスでGithub Enterpriseを使うことになり、Github enterpriseではBitBucketの自動マージングが標準ではサポートされていなかったため、やり方を見直す必要がでてきた

Githubにも標準の自動マージ機能はあるが、用語の意味が異なる

Github

PRが承認され自動テストも通った場合に自動でPRをマージする
https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request

BitBucket

releaseブランチにマージした時、それより未来のreleaseブランチにもマージする
https://confluence.atlassian.com/bitbucketserver089/automatic-branch-merging-1236435695.html

従来の開発スタイル

B to B to Cの比較的規模の大きめのサービスであり、即日~数日でリリースする小規模なものもあれば、半年以上かける大規模なものもあり、かつ複数同時に走ることがある

そのため複数のreleaseブランチが平行して存在していることも珍しくはなく、
featureブランチからreleaseブランチにマージした後はreleaseブランチ間、及びreleaseブランチからdevelopブランチ間を自動でマージしてくれるBitBucketの自動マージング機能が重宝していた

従来の小さな問題点

• リリースを終えたreleaseブランチをmasterブランチへマージするのはいいが、その後にmasterブランチを次のreleaseブランチにマージしなおすのがやや手間（自動化は検討していた）
• masterブランチは管理上存在しているが、それを直接使うことはあまりない

なぜgit flowは廃れたか

10年前にA successful Git branching modelを見て導入を決めたが、本人が追記している通り、昨今の自動化が進んだwebアプリには必要以上に複雑で合わない場合が多いため
とはいえ万能薬ではなかったというだけで、複数バージョンを同時に開発することのあるうちのような開発スタイルには合っていた

他の有名な開発手法との比較対象

例えばgithub flowは軽量な手法として今一番人気があると思われるgitブランチモデルだが、大規模な複数のラインが走る開発には向いておらず、他の方法も同様の傾向が見られたため採用を見送った

結論

既存のルールでは自分たちの開発スタイルに合わないことがわかり、
開発スタイルをそのために変えるのは本末転倒、かつ短期間で変えるのは問題が多いということで、
当面はgit flowをベースに一部を見直したルールで運用することにした

まずは直近のリリースブランチを作成するのをやめ、masterブランチに兼任させた
これによりリリース後のmasterブランチへのマージが不要になり、hotfixが必要な場合は直近のtagから生成することにした

また、当面の間は自動マージングを手動で運用することにした
こちらはGithub actionsを使えば自動化はできるが、将来的により軽量な開発サイクルへの移行を期待し、
複数の大型リリースブランチが混在すること自体を避けるようにするための試みとして決定した

感想

github flow以外にも名前がついている開発手法はいくつかあるが、
実際に試してみないとイメージが掴みづらく、思ったよりも決定に時間がかかった

ブランチモデルの命名ルールによる検索性の低さからか、あるいは単純に興味を持つ人がすくないのか、gitの利用者数の割にブランチモデルのついての議論が少ないように思われた

特に見直すタイミングがなく、深く考えないまま10年も続けていたやり方なので、自分たちの開発スタイルも含めて見直すいい切っ掛けとなった