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

 2021/05/28
github-switch-default-branch

はじめに

概要

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

Git Flow とは?

まず develop というブランチを採用するかといった議論があると思います。
Git のブランチを運用するブランチモデルとしては Git FlowGitHub Flow が有名です。
fwywd のチームでもどのようなブランチモデルがベストであるか検討中ですが、現状では Git Flow を採用しています。
gitflow
ただし、少人数のチームで 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 をとてもわかりやすく解説されています。
今回は現状の fwywd チームで採用している Git Flow を前提として、main ブランチで本番環境の運用、develop ブランチで開発を進めるといった方針とします。

手順の解説

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

デフォルトのブランチを main から develop へ

まず、ブランチの設定周りは Settings > Branches で確認することができます。
github01
以下の手順に示すように、ブランチを develop へ変更するだけです。
github02
github03
develop ブランチが Default branch に表示されていれば完了です。
github04
Code のページでも develop がデフォルトのブランチとして指定されているか確認しておきましょう。
github05
これで各種 Pull Request を送るときの base となるブランチが develop になります。

main ブランチを削除から保護

Git Flow では hotfixes といって本番環境で即座に修正したい微細なミスを main(旧 master) ブランチに直接マージさせる方法を取ります。
gitflow
そのため、定期的に main から develop ブランチへ Pull Request を送ってマージさせることがあり、この Pull Request のマージが終わった後に、マージが終わった後の main ブランチを削除しますか?と聞かれ、delete と押してしまうと main ブランチがなくなってしまいます。 ※ 厳密な Git Flow では hotfixes から develop ブランチにマージされるようになって、この問題は回避できるのですが、実際に運用してみると、hotfixes > main > develop とマージしていく方が自然だと感じています。
main ブランチを Vercel などのデプロイ先に指定している場合も多く、ソースコード自体が無事でも本番環境のデプロイが失敗してしまう原因となります。
main ブランチを人為的に削除してしまうミスを防げるに越したことはありません。
この main ブランチを削除から保護する方法はとても簡単です。
Branch protection rules を GitHub では設定することができます。
github06
github07
github08
たったこれだけで main ブランチが削除される問題から保護することができます。
手順の途中にあったように、Pull Request 時のレビューを必須にしたり、直接の push を防いだりできますので、この辺りも必要に応じて設定しましょう。

おわりに

人為的なミスは設定で防げる

情報漏洩などのセキュリティの事故は 大半が人為的なミス だと言われています。
GitHub など人為的なミスが起きやすいツールでは、プロジェクトの管理者が事前にそのようなミスを防げるように設定しているかが後々の大きな失敗から守ってくれるはずです。
問題が起きなくても感謝はされにくいところですが、知らなかったでは済まされないため、この辺りの設定もしっかりと学んでいけると良いですね。
今回も fwywd の記事をお読みいただき、誠にありがとうございました。
株式会社キカガク 代表取締役会長
吉崎 亮介
twitter: @yoshizaki_91

fwywd では開発メンバーを募集しています

recruitment
fwywd では採用試験を無料で公開しています。
採用への応募の有無を問わず、Web アプリケーションの開発を学びたい多くの方にとって有益な試験内容となるように設計しています。 ぜひ、fwywd の面白い採用試験を覗いてみてください。