GitHub でデフォルトのブランチを main から develop へ変更した後に main ブランチを削除から守る方法

GitHub ではリポジトリを作成した時のデフォルトのブランチが main ですが、Git Flow などのブランチモデルを適用すると、main は基本的に本番環境運用のためだけに存在させるべきです。
デフォルトのブランチが main のままだと Pull Request を出すときの base となるブランチが常に main となってしまい、変更の手間が面倒であったり人為的なミスが生じてしまいます。
そこで、今回はデフォルトのブランチを main から develop へ変更する方法を紹介します。

また、単にデフォルトのブランチを変更しただけでは、hotfixes の変更などを main から develop へ Pull Request でマージした時にブランチを誤って削除してしまう危険性があります。
そこで、main ブランチを人為的なミスで削除から守る方法も併せて紹介します。

まず develop というブランチを採用するかといった議論があると思います。
Git のブランチを運用するブランチモデルとしては Git Flow と GitHub Flow が有名です。
fwywd のチームでもどのようなブランチモデルがベストであるか検討中ですが、現状では Git Flow を採用しています。

出典：A successful Git branching model

ただし、少人数のチームで develop ブランチをわざわざ分ける必要があるかと聞かれると、確かにレビューの仕組みを整えておけば develop ブランチがなくても成立するように感じます。

Git Flow に対して、GitHub Flow ではこの develop ブランチが不要であると唱え、main（旧 master）ブランチに feature/*** ブランチを作って Pull Request を送ってマージしていく方法です。
以下の記事によると、2011 年の GitHub の開発チーム 35 人程度では問題なく Git Flow よりも効率良く運用できているという主張があります。

参考：GitHub Flow

GitHub のチームが 35 人の頃なんて想像もつかないですが、この辺りの結論はもう少し吟味してから出したいと思います。 なお、GitLab Flow も存在し、Git Flow や GitHub Flow の足りない点を補っているようです。
以下の記事が GitLab Flow をとてもわかりやすく解説されています。

参考：GitLab Flow + GitHub Actions ではじめる、デプロイフローの改善・自動化 - エクサウィザーズ Engineer Blog

今回は現状の fwywd チームで採用している Git Flow を前提として、main ブランチで本番環境の運用、develop ブランチで開発を進めるといった方針とします。

今回の手順は GitHub の GUI 操作だけで完結できるため、とても簡単です。
事前準備として、develop ブランチを操作するリポジトリに作っておきましょう。

まず、ブランチの設定周りは Settings > Branches で確認することができます。

以下の手順に示すように、ブランチを develop へ変更するだけです。

develop ブランチが Default branch に表示されていれば完了です。

Code のページでも develop がデフォルトのブランチとして指定されているか確認しておきましょう。

これで各種 Pull Request を送るときの base となるブランチが develop になります。

Git Flow では hotfixes といって本番環境で即座に修正したい微細なミスを main（旧 master） ブランチに直接マージさせる方法を取ります。

出典：A successful Git branching model

そのため、定期的に main から develop ブランチへ Pull Request を送ってマージさせることがあり、この Pull Request のマージが終わった後に、マージが終わった後の main ブランチを削除しますか？と聞かれ、delete と押してしまうと main ブランチがなくなってしまいます。 ※ 厳密な Git Flow では hotfixes から develop ブランチにマージされるようになって、この問題は回避できるのですが、実際に運用してみると、hotfixes > main > develop とマージしていく方が自然だと感じています。

main ブランチを Vercel などのデプロイ先に指定している場合も多く、ソースコード自体が無事でも本番環境のデプロイが失敗してしまう原因となります。
main ブランチを人為的に削除してしまうミスを防げるに越したことはありません。
この main ブランチを削除から保護する方法はとても簡単です。

Branch protection rules を GitHub では設定することができます。

たったこれだけで main ブランチが削除される問題から保護することができます。
手順の途中にあったように、Pull Request 時のレビューを必須にしたり、直接の push を防いだりできますので、この辺りも必要に応じて設定しましょう。

情報漏洩などのセキュリティの事故は 大半が人為的なミス だと言われています。
GitHub など人為的なミスが起きやすいツールでは、プロジェクトの管理者が事前にそのようなミスを防げるように設定しているかが後々の大きな失敗から守ってくれるはずです。
問題が起きなくても感謝はされにくいところですが、知らなかったでは済まされないため、この辺りの設定もしっかりと学んでいけると良いですね。

今回も fwywd の記事をお読みいただき、誠にありがとうございました。

株式会社キカガク 代表取締役会長
吉崎 亮介
twitter: @yoshizaki_91