@kyanny さんの記事を自分なりに整理してみる。
ずっと「マージした後にメインブランチを production デプロイする」というワークフローだと勘違いしていた。
昔は「マージ後にデプロイ」だったが、いつの頃からか「マージ前にデプロイ」に変わったらしい。
どこかでそんな話は聞いていたけど、実際のところはどうなんだろう？と以前から疑問だった。やっぱりそうだったか。
現在の GitHub flow
というか、GiHub の公式ガイドにそのものズバリ書いてあったのね。灯台下暗し…。
Understanding the GitHub flow · GitHub Guides
“>” を数回クリックし、“Deploy” に進むと書いてある。
With GitHub, you can deploy from a branch for final testing in production before merging to main.
main ブランチにマージする前に、最後の確認をするために本番環境にデプロイする。
If your branch causes issues, you can roll it back by deploying the existing main branch into production.
もし問題が発生したら、main ブランチを本番環境にデプロイすることでロールバック出来る。
main ブランチの protection rule は “Require branches to be up to date before merging” を有効にしているのかな。いずれにせよ、main ブランチの commit 全部入りのブランチをデプロイしているはず。
以前の GitHub flow
2011/8/31 の GitHub Flow – Scott Chacon にまとまっている。この頃の GitHub は従業員 35 人だったそう。
“we can merge it into master for deployment” とあるので、この頃は確かに master ブランチにマージしたあとにデプロイしていたようだ。
自分なりの整理
Git は元々 Linux カーネルのバージョン管理をするためのツールとして開発された。その Linux カーネルの開発ではその性質上、Git Flow という重厚なブランチ戦略が使われていた。
GitHub flow は Web アプリケーションに合った軽量なブランチ戦略として誕生し、時を経てその内容も変わっていた。
以前の GitHub flow を v1、現在の GitHub flow を v2 と勝手にバージョニングすることにした。
P.S.
Apple っぽくするのだったら「新しい GitHub flow」なのかな？(^^;
追記(2021-03-15):
会社の同僚から「main（デフォルト）ブランチを常にリリース可能な状態に保つ」というルールが守られていれば、それが広義の GitHub flow でいいんじゃない？みたいな話を聞きました。なるほど。