GitのMainおよびMaster Branch：その概要とメインブランチが必要な理由

GitのMain / Master Branchとは

Main Branch（またはMaster — リポジトリ設定に依存）は、Gitリポジトリを初期化するときに作成されるデフォルトのブランチです。これはプロジェクトのメインブランチであり、プロダクションにデプロイする準備ができたコードを含んでいます。

新しい機能を使った日々の作業が盛んに行われるdevelopとは異なり、mainはプロジェクトのショーケースです。mainのコードの各バージョンは、featureブランチでの開発、developへの統合、releaseブランチでのリリース準備、最終テストという完全なサイクルを経ています。その後でのみ、変更がmainに到達します。

重要な原則：mainは常に安定している必要があります。mainでエラーが見つかった場合、緊急のhotfixを順番外でリリースする必要があります。そのため、プロフェッショナルなプロジェクトでは、mainはブランチ保護ルールによって偶発的な変更から保護されています。

Git Bookによると、mainは特別なプロパティを持つ特別なブランチではなく、慣例によりメインと見なされるコミットへの通常の参照です。Gitはシステムレベルでmainと他のブランチを区別しません。

masterからmainへの移行

歴史的に、Gitのデフォルトブランチはmasterと呼ばれていました。2020年6月、Black Lives Matter運動がIT業界のmasterとslaveという用語に注目を集めました。GitHubはデフォルトブランチにmainという用語への移行を発表しました。

2020年10月以降、GitHubのすべての新しいリポジトリはmainブランチで作成されます。GitLabとBitbucketもデフォルト名としてmainのサポートを実装しました。Git 2.28（2020年7月）では、デフォルトのブランチ名を設定するためのinit.defaultBranchオプションが追加されました。

技術的には、既存のブランチをmasterからmainに名前変更するのは簡単な操作です。主な課題は、CI/CD設定、ドキュメント、開発者のローカルリポジトリのすべての参照を更新することです。

既存のリポジトリでブランチの名前を変更するには、次を実行します：

# masterをローカルでmainに名前変更
git branch -m master main

# リモートリポジトリを更新
git push -u origin main

# サーバー上の古いmasterを削除
git push origin --delete master

# サーバー上のHEADを更新
# （GitHub Webインターフェース経由：Settings → Branches → Default branch）

Git FlowとGitHub Flowにおけるmainの役割

Git FlowとGitHub Flowは、mainブランチの役割を異なる方法で定義します。モデルの選択は、チームのサイズ、リリース頻度、コードの安定性要件によって異なります。

モバイル開発では、Git Flowが標準です。App StoreやGoogle Playでのアプリ公開には固定のリリースサイクルがあるためです。GitHub Flowは、1日複数回デプロイできるWebプロジェクトに適しています。

GitHub Flow — 簡略化されたアプローチ

GitHub Flowには、developブランチはありません。すべてのfeatureブランチはmainから直接作成され、完了後はPull Requestを介してマージされます。mainへの各マージは、自動的にプロダクションへのデプロイをトリガーします。このモデルには、高いレベルのテスト自動化とチームの規律が必要です。

GitHub Flowには、developブランチはありません。すべてのfeatureブランチはmainから直接作成され、完了後はPull Requestを介してマージされます。mainへの各マージは、自動的にプロダクションへのデプロイをトリガーします。このモデルには、高いレベルのテスト自動化とチームの規律が必要です。

mainブランチの保護

mainのブランチ保護は、商業プロジェクトでは必須の設定です。これがないと、偶発的なプッシュによって未完成のコードが本番環境に送信されたり、すべてのユーザーに対して動作中のアプリケーションが壊れたりする可能性があります。

• Require pull request — mainへの直接プッシュは禁止。すべての変更はレビュー付きのPR経由。
• Require approvals — mainにマージするには最低2つの承認が必要（レビュー担当者が見逃した場合に備えて）。
• Require status checks — マージ前にすべてのCI/CDチェックが成功する必要があります。
• Require up-to-date — PRは最新のmainコミットに基づいている必要があります。
• Include administrators — 保護はリポジトリ所有者にも適用されます。
• Require signed commits — mainのすべてのコミットはGPGキーで署名される必要があります。

6つすべてのルールを設定することは、10,000人以上のユーザーがいるモバイルプロジェクトの標準です。小規模プロジェクトでは、最初の3つのルールで十分です。

さまざまなプロジェクトタイプの保護レベルの比較

mainの保護レベルはプロジェクトの規模によって異なります。スタートアップは最小限の保護で済みますが、エンタープライズアプリケーションには最大の制限が必要です。

mainのリリースとタグ

タグ付けは、main内の特定のコミットに名前付き参照を作成するプラクティスです。各タグは、本番環境にリリースされたアプリケーションのバージョンに対応します。これにより、デバッグやパッチ適用のために以前のリリースにすばやく切り替えることができます。

モバイル開発におけるタグ命名の標準は、SemVer（セマンティックバージョニング）です：v1.2.3。最初の数字はメジャーバージョン（互換性を破る変更）、2番目はマイナーバージョン（新機能）、3番目はパッチ（修正）です。

タグは、releaseブランチがmainにマージされた後に作成されます。このコミットはCI/CDでビルドされ、署名され、アプリストアに送信されます。タグでエラーが見つかった場合、そのタグからhotfixブランチが作成されます。

# 注釈付きリリースタグを作成
git tag -a v2.4.1 -m "Release version 2.4.1"

# サーバーにタグを送信
git push origin v2.4.1

# リポジトリ内のすべてのタグを表示
git tag -l "v2.*"

# 特定のタグからhotfixブランチを作成
git checkout -b hotfix/crash-fix v2.4.1

Git Flowブランチ階層

Git Flowのブランチ階層を理解することは、協調的な開発を適切に組織するための基盤です。各ブランチタイプには、独自のソース、目的、マージルールがあります。

• Main（レベル1） — ルートブランチ。リリースバージョンのみを含む。リポジトリ初期化時に作成。
• Develop（レベル2） — プロジェクト開始時にmainから作成。すべての機能の統合コードを含む。
• Feature（レベル3） — developから作成。個々の機能の独立した開発。
• Release（レベル2） — developから作成。特定のリリースを公開用に準備。
• Hotfix（レベル2） — mainから作成。本番環境の重大なエラーの緊急修正。

重要なルール：featureは決して直接mainにマージされません。feature → develop → release → mainが正しいマージチェーンです。このルールに違反すると、Git Flowモデル全体の目的が無効になります。

mainを操作するコマンド例

シナリオを考えてみましょう：チームがリリースv2.5.0の準備を完了しました。releaseブランチはレビューされ、mainにマージする準備ができています。マージ後、タグが作成され、リリースが公開されます。

# mainに切り替えて更新
git checkout main
git pull origin main

# 検証済みのreleaseブランチをマージ
git merge --no-ff release/2.5.0

# リリースタグを作成
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# mainとタグをサーバーに送信
git push origin main --tags

--no-ffフラグ（fast-forwardなし）は、単にポインタを移動するだけでマージが実行できた場合でも、マージコミットの作成を保証します。これにより、変更がreleaseブランチから来たという情報が保存され、履歴分析が容易になります。

mainを介したhotfixの操作

本番環境で重大なエラーが発見された場合、プロセスは通常のリリースとは異なります。hotfixはmainから作成され、修正後、mainとdevelopの両方にマージされます。

本番環境で重大なエラーが発見された場合、プロセスは通常のリリースとは異なります。hotfixはmainから作成され、修正後、mainとdevelopの両方にマージされます。

# mainからhotfixブランチを作成
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# 修正してコミット
git add src/fix/
git commit -m "Fix crash on login screen"

# hotfixをmainにマージ戻す
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# hotfixをdevelopにもマージ
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# hotfixブランチを削除
git branch -d hotfix/2.5.1-crash-fix