#8 デフォルトブランチをdevelopに変更する理由 - Python OSS開発記録
karrinn
著者
Git Flowを採用したプロジェクトで、デフォルトブランチがmainのままになっていませんか？
GitHubのデフォルトブランチをdevelopに変更しておくだけで、「PRがmainに向いてる！」「cloneしたらmainだった！」といった混乱を未然に防げます。
KEY TAKEAWAYS
この記事でわかること
- Git Flowでデフォルトブランチをdevelopにする理由
- デフォルトブランチ変更の影響範囲（PR・clone・Issue）
- gh CLIとWeb UIでの変更手順
用語の定義
TERM 01
デフォルトブランチ
GitHubリポジトリのメインとなるブランチです。リポジトリをcloneした時に自動的にcheckoutされ、PRのデフォルトのマージ先、Issue作成時の基準など、多くの操作の起点となります。
TERM 02
develop ブランチ
Git Flowにおける開発の中心ブランチです。すべてのfeature/fixブランチはここから切り、ここにマージされます。次期リリースの統合ブランチとして機能します。
TERM 03
main ブランチ
Git Flowにおける本番環境ブランチです。常に本番デプロイ可能な状態を保ち、developから作られたreleaseブランチ、またはhotfixブランチのみがマージされます。
TERM 04
ベースブランチ
PRを作成する際、どのブランチにマージするかを指定する対象ブランチです。Git Flowではfeature/fixブランチのベースブランチはdevelopになります。
なぜデフォルトブランチをdevelopに変更するのか
Git Flowを採用したプロジェクトでは、開発の中心はdevelopブランチです。Vincent Driessenが提唱したオリジナルのGit Flowモデルでも、developブランチは「次期リリースの最新の開発変更を常に反映するブランチ」と定義されています。しかしGitHubのデフォルトブランチは最初mainに設定されているため、そのままでは矛盾が生じます。
デフォルトブランチがmainのままだと起きる問題
問題1: PRのマージ先が間違う
feature/xxxブランチからPRを作ると、デフォルトでmainに向かってしまいます。
本当はdevelopにマージすべきなのに、毎回手動で変更する必要が出てきます。
問題2: cloneしたらmainになる
git cloneすると、デフォルトブランチがcheckoutされます。
新規参画者が「あれ、developどこ？」と混乱するケースが多発します。
問題3: READMEがdevelopと同期しない
GitHubのトップページに表示されるREADMEはデフォルトブランチのものです。
developで更新しても、リポジトリのトップページには反映されません。
問題4: Issueのリンクがmainを参照
Issue作成時、コードへのリンクはデフォルトブランチを参照します。
developで開発しているのに、mainのコードが表示されてしまいます。
結論: 初日に変更しておきましょう
Git Flowを採用したら、初日にデフォルトブランチをdevelopに変更してください。これだけで、新規参画者が「どっちで作業すればいいの？」と迷わなくなります。
デフォルトブランチ変更の影響範囲
デフォルトブランチを変更すると、リポジトリのいろんな場所に影響します。事前に把握しておくと安心です。
| 影響する操作 | 変更前（main） | 変更後（develop） |
|---|---|---|
| git clone | mainがcheckoutされる | developがcheckoutされる |
| PR作成時のベース | デフォルトでmainに向く | デフォルトでdevelopに向く |
| README表示 | mainのREADMEを表示 | developのREADMEを表示 |
| Issueのコードリンク | mainを参照 | developを参照 |
| GitHub API | mainを返す | developを返す |
| GitHub Actions | mainブランチをトリガー | developブランチをトリガー（要確認） |
GitHub Actionsの挙動に注意
on: pushやon: pull_requestのワークフローは、デフォルトブランチの変更で挙動が変わる場合があります。既にワークフローがある場合、変更前にyamlファイルを確認してみてください。
デフォルトブランチの変更手順
デフォルトブランチの変更は、GitHub CLI（gh）またはWeb UIで行えます。どちらも簡単なので、お好みの方法で試してみてください。
前提条件
デフォルトブランチを変更する前に、以下を確認してください：
- developブランチが存在する → トピック#4のGit Flow設計で作成済みであること
- developブランチがpushされている → リモートに存在する必要があります
- Admin権限がある → リポジトリ設定を変更するため必要です
おすすめ: コマンドラインで素早く変更できます。wagtail-reusable-blocksでもこの方法を使いました。
現在のデフォルトブランチを確認
まずは今の設定を確認してみましょう。--jsonと--jqオプションで、必要な情報だけを取り出せます。
defaultBranchRef: デフォルトブランチの参照情報.name: ブランチ名のみを抽出
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' # 出力例 main
デフォルトブランチをdevelopに変更
gh repo editコマンドで、リポジトリの設定を変更できます。--default-branchオプションでブランチ名を指定するだけです。
--default-branch: 新しいデフォルトブランチ名- 指定するブランチは事前に存在している必要があります
gh repo edit --default-branch develop # 出力例 ✓ Edited repository kkm-horikawa/wagtail-reusable-blocks
変更を確認
最初と同じコマンドで、変更が反映されたか確認してみましょう。developと表示されれば成功です。
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' # 出力例 develop
Web UIから変更する場合は、以下の流れで行います。視覚的に操作できるので、CLIに慣れていない方にもおすすめです。
- 01
リポジトリのSettings → Generalを開く
GitHubリポジトリのトップページから、
Settingsタブをクリックします。 - 02
「Default branch」セクションを探す
ページの上部に表示されています。現在のデフォルトブランチ名が表示されているはずです。
- 03
ブランチ切り替えアイコンをクリック
現在のデフォルトブランチ（main）の横にある、矢印の切り替えアイコンをクリックします。
- 04
「develop」を選択して「Update」をクリック
ドロップダウンから
developブランチを選択し、確認ダイアログでI understand, update the default branch.をクリックします。
複数リポジトリで作業するならCLIがおすすめ
Web UIは視覚的でわかりやすいですが、gh CLIの方が速いです。複数リポジトリで同じ設定をしたい場合は、CLIでスクリプト化するのも良いでしょう。
Source: gh repo edit - GitHub CLI Manual
変更後の確認事項
デフォルトブランチを変更したら、以下の項目を確認しておくと安心です。
READMEが最新か確認
GitHubリポジトリのトップページをリロードして、developブランチのREADMEが表示されているか確認してみてください。
PRのベースがdevelopになるか確認
試しにfeatureブランチからPRを作成し、base branchがdevelopになっているか確認してみてください。
cloneしてdevelopになるか確認
別のディレクトリでgit cloneして、developブランチがcheckoutされるか確認してみてください。
GitHub Actionsの挙動確認
既存のワークフローがある場合、developブランチでトリガーされるか確認してみてください。
OSS vs 企業プロジェクト: 変更のタイミング
デフォルトブランチを変更するタイミングも、プロジェクトの性質で少し変わってきます。
OSS: 初日に変更して、開発の透明性を保つ
wagtail-reusable-blocksのようなOSSプロジェクトでは、初日にデフォルトブランチをdevelopに変更しました。
理由1: コントリビューターが迷わない
外部コントリビューターが「PRどこに出せばいいの？」と迷わずに済みます。
デフォルトブランチがdevelopなら、自然にdevelopベースでPRが作られます。
理由2: READMEが開発状況を反映
GitHubトップページのREADMEがdevelopブランチの最新状態を表示します。
「開発中の機能」や「次期リリース予定」を示せるのは大きなメリットです。
理由3: Issueのコードリンクが正確
Issueから「このコードどこ？」とリンクを貼る時、developブランチを参照します。
開発中の機能について議論する時、正しいコードを見られるのは重要です。
OSSはdevelopを中心に回るので、初日にデフォルトブランチを変更しておくのがおすすめです。透明性を保ち、コントリビューターが迷わない環境を作れます。
企業: 新人が「どこで作業すればいいの？」と迷わない環境を作る
企業プロジェクトでも、Git Flowを採用したら初日にdevelopに変更しておくことをおすすめします。
これは新人の萎縮を防ぐための技術的な防御策でもあります。
よくある悲劇: デフォルトブランチがmainのままだと...
- 新人が
git cloneすると、mainブランチがcheckoutされる - そのままfeatureブランチを切ってしまう → mainから派生してしまう
- PR作成時、デフォルトでmainに向く → 気づかずmainにマージしようとする
- 先輩に「mainに出すなよ！developだろ！」と指摘される
- → 新人は萎縮し、「何をやっても怒られる」と思い込んでしまう
システムで防げば、新人は安心して作業できる
デフォルトブランチをdevelopに変更しておけば：
git clone→ 自動的にdevelopがcheckout- PR作成 → 自動的にdevelopがベース
- → 何も考えなくても正しい場所で作業できる
- → 新人が「えい」って試せる環境 = 経験値が溜まりやすい
企業プロジェクトこそ、初日にデフォルトブランチをdevelopに変更しておきましょう。新人が迷わず、安心して失敗できる環境を技術的に作ることができます。これは教育の本質でもあります。
Source: Branches in a Gitflow strategy - AWS Prescriptive Guidance
よくある質問
A: 既存のPRには影響しません。
デフォルトブランチの変更は、新しく作成されるPRのデフォルト値に影響するだけです。
既に開いているPRのベースブランチは変わりませんので、安心してください。
A: いいえ、mainブランチは残してください。
Git Flowでは、mainは本番環境ブランチとして機能します。
デフォルトブランチがdevelopになっても、mainは重要な役割を持っています。
削除すると、リリースプロセスが壊れてしまいます。
A: 既存のローカルリポジトリには影響しません。
デフォルトブランチの変更は、新しくcloneする時の挙動に影響します。
既にclone済みのローカルリポジトリは、変更前の状態のままです。
既存メンバーがdevelopに切り替えるには:
git checkout develop git pull origin develop
A: はい、GitHub Flowならmainのままで大丈夫です。
GitHub Flow: mainブランチが開発・本番両方の中心。デフォルトブランチ = main
Git Flow: developブランチが開発の中心。デフォルトブランチ = develop
ブランチ戦略によって、デフォルトブランチの最適解が変わります。
A: リポジトリのAdminに依頼してください。
デフォルトブランチの変更には、リポジトリのAdmin権限が必要です。
Write権限だけでは変更できません。
依頼する時のポイント:
- 「Git Flowを採用したため、デフォルトブランチをdevelopに変更してほしい」
- 「新規参画者がPRのベースブランチを間違えないため」
- 「この記事を読んでもらえると理解しやすいです」← このページのURL
A: はい、同じ手順で戻せます。
デフォルトブランチの変更は、何度でも変更可能です。
間違えても、すぐに元に戻せますので安心してください。
mainに戻す場合
同じgh repo editコマンドで、ブランチ名を変えるだけです。
# mainに戻す場合 gh repo edit --default-branch main # 確認 gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
まだコメントはありません。最初のコメントを残しませんか？