GitHubのブランチとは？初心者のためのブランチ＆バージョン管理

プログラミングの学習を始めてGitHubを使い始めると、「mainブランチって何？」「ブランチはどう使い分ければいいの？」「タグって必要なの？」といった疑問にぶつかることがあります。

私自身も最初は、これらの概念の違いや使い方がよくわからず、試行錯誤しながら学んできました。

この記事では、GitHubの基本的な概念である「mainブランチ」「ブランチ」「タグ（バージョン管理）」について、初心者の方にも理解しやすいように、実際の開発フローに沿って解説していきます。

実際のプロジェクトで使える実践的な知識を身につけていきましょう。

mainブランチとは？ - プロジェクトの「顔」となる大切な場所

mainブランチの役割を理解しよう

mainブランチ（以前はmasterブランチと呼ばれていました）は、プロジェクトの「正式版」「本番環境」にあたる特別なブランチです。家に例えると、お客様をお迎えするリビングルームのような存在といえます。

常に整理整頓され、いつでも人に見せられる状態を保つ必要があります。

mainブランチには以下のような特徴があります。

• 常に動作する安定したコードが置かれている
• チームメンバー全員が参照する基準となる
• 製品版としてリリースできる品質を保つ
• 直接編集することは避けるべき（保護されていることが多い）

なぜmainブランチを特別扱いするのか

開発を進めていく中で、新機能の追加やバグ修正など、様々な変更を加える必要があります。

しかし、これらの作業を直接mainブランチで行うと、以下のような問題が発生する可能性も。

1. 作業中のコードが不完全な状態で公開されてしまう
2. バグを含むコードが本番環境に反映されてしまう
3. 複数人で開発している場合、お互いの作業が衝突する
4. 問題が発生した時に、以前の安定版に戻すことが困難になる

これらの問題を避けるために、mainブランチは「完成品を置く場所」として特別に扱い、開発作業は別のブランチで行うというルールが生まれました。

ブランチで安全に開発を進める方法

ブランチの基本概念 - 自分だけの作業スペース

ブランチ（branch）は、文字通り「枝」を意味します。mainブランチという幹から枝分かれした、独立した作業スペースだと考えてください。

部屋に例えると、散らかしても大丈夫な自分の作業部屋のような存在です。

ブランチを使うメリットは以下の通りです。

• mainブランチに影響を与えずに自由に実験できる
• 失敗しても簡単に削除・やり直しができる
• 複数の機能を並行して開発できる
• チームメンバーと作業を分担しやすい

ブランチの命名規則 - わかりやすい名前をつけよう

ブランチには、その目的がひと目でわかる名前をつけることが重要です。一般的な命名規則として以下のようなパターンがあります。

• feature/機能名：新機能を追加する場合（例：feature/user-login）
• fix/バグ名：バグを修正する場合（例：fix/button-click-error）
• hotfix/緊急修正名：緊急の修正が必要な場合（例：hotfix/security-patch）
• release/バージョン番号：リリース準備用（例：release/v1.2.0）

ブランチ作成からマージまでの具体的な流れ

実際にブランチを使った開発の流れを、ステップバイステップで見ていきましょう。

ステップ1：新しいブランチを作成する

# 現在のブランチを確認
git branch

# mainブランチに移動
git checkout main

# 最新の状態を取得
git pull origin main

# 新しいブランチを作成して移動
git checkout -b feature/add-search-function

このコマンドで、mainブランチから分岐した新しいブランチ「feature/add-search-function」が作成され、自動的にそのブランチに移動します。

ステップ2：開発作業を進める

新しいブランチで自由に開発を進めます。この段階では、mainブランチには一切影響がないので、安心して試行錯誤できます。

# ファイルを編集した後、変更内容を確認
git status

# 変更をステージングエリアに追加
git add .

# コミット（変更を記録）
git commit -m "検索機能の基本実装を追加"

# リモートリポジトリにプッシュ
git push origin feature/add-search-function

ステップ3：プルリクエスト（Pull Request）を作成する

開発が完了したら、GitHubのウェブサイト上でプルリクエストを作成します。プルリクエストは、「このブランチの変更をmainブランチに取り込んでください」という申請のようなものです。

プルリクエストでは以下の情報を記載します。

• 変更の概要：何を追加・修正したのか
• なぜこの変更が必要なのか
• テスト方法：動作確認の手順
• スクリーンショット：UI変更がある場合は画像を添付

ステップ4：レビューとマージ

チームメンバーがコードをレビューし、問題がなければマージ（統合）します。個人開発の場合も、自分でレビューしてからマージする習慣をつけると良いでしょう。

# マージ後、ローカルのmainブランチを更新
git checkout main
git pull origin main

# 不要になったブランチを削除
git branch -d feature/add-search-function

タグでバージョンをしっかり記録する

タグ（Tag）とは何か - 特定の時点を記録する仕組み

タグは、特定のコミット（変更の記録）に対して付ける「しおり」のようなものです。本のページに付箋を貼るように、「ここがバージョン1.0です」「ここがバージョン1.1です」と目印をつけることができます。

タグを使うメリット。

• リリースしたバージョンを明確に記録できる
• 過去のバージョンに簡単に戻れる
• 変更履歴を追いやすくなる
• ユーザーに対してバージョン番号を明示できる

セマンティックバージョニング - バージョン番号の付け方

バージョン番号は「1.2.3」のような形式で表現されることが多く、これをセマンティックバージョニングと呼びます。それぞれの数字には意味があります。

• メジャーバージョン（1.x.x）：大きな変更、互換性のない変更
• マイナーバージョン（x.2.x）：新機能の追加、互換性は維持
• パッチバージョン（x.x.3）：バグ修正、小さな改善

例えば、

• v1.0.0：最初のリリース
• v1.1.0：新機能を追加
• v1.1.1：バグを修正
• v2.0.0：大幅な仕様変更

タグの作成と管理方法

基本的なタグの作成

# 現在のコミットにタグを付ける
git tag v1.0.0

# メッセージ付きタグ（推奨）
git tag -a v1.0.0 -m "初回リリース版"

# タグをリモートリポジトリにプッシュ
git push origin v1.0.0

# すべてのタグをプッシュ
git push origin --tags

過去のコミットにタグを付ける

# コミット履歴を確認
git log --oneline

# 特定のコミットにタグを付ける
git tag -a v0.9.0 abc1234 -m "ベータ版リリース"

GitHub Releasesの活用 - より詳細なリリース管理

GitHubには「Releases」という機能があり、タグをベースにしてより詳細なリリース情報を管理できます。

Releaseを作成する手順

1. GitHubのリポジトリページで「Releases」をクリック
2. 「Create a new release」ボタンをクリック
3. タグを選択（または新規作成）
4. リリースタイトルと説明を記入
5. 必要に応じてバイナリファイルを添付
6. 「Publish release」で公開

Releaseに含める情報

• 変更内容の概要：新機能、修正内容、改善点
• 既知の問題：未解決のバグや制限事項
• アップグレード手順：以前のバージョンからの移行方法
• 謝辞：貢献者への感謝

実践的な開発フローの例

Chrome拡張機能開発での具体例

実際のChrome拡張機能開発を例に、これまで学んだ内容を統合して見てみましょう。

初期開発（v1.0.0）

# プロジェクトの初期化
git init
git add .
git commit -m "初期コミット"

# GitHubにプッシュ
git remote add origin https://github.com/username/my-extension.git
git push -u origin main

# 開発が完了したらタグを付ける
git tag -a v1.0.0 -m "初回リリース - 基本機能実装"
git push origin v1.0.0

新機能の追加（v1.1.0）

# 新機能用のブランチを作成
git checkout -b feature/add-dark-mode

# 開発作業...
# コミット、プッシュ、プルリクエスト、マージ

# マージ後、タグを付ける
git checkout main
git pull origin main
git tag -a v1.1.0 -m "ダークモード機能を追加"
git push origin v1.1.0

緊急バグ修正（v1.1.1）

# hotfixブランチを作成
git checkout -b hotfix/fix-crash-on-startup

# 修正作業...
# 迅速にマージ

# パッチバージョンのタグを付ける
git tag -a v1.1.1 -m "起動時のクラッシュを修正"
git push origin v1.1.1

トラブルシューティング - よくある問題と解決方法

マージコンフリクトが発生した場合

複数のブランチで同じファイルの同じ部分を編集すると、マージ時にコンフリクト（衝突）が発生することがあります。

# コンフリクトの確認
git status

# ファイルを開いて手動で解決
# <<<<<<< HEAD
# 現在のブランチの内容
# =======
# マージしようとしているブランチの内容
# >>>>>>> branch-name

# 解決後、コミット
git add .
git commit -m "コンフリクトを解決"

間違えてmainブランチで作業してしまった場合

# 変更を一時的に退避
git stash

# 新しいブランチを作成
git checkout -b feature/my-changes

# 退避した変更を適用
git stash pop

タグを間違えて付けてしまった場合

# ローカルのタグを削除
git tag -d v1.0.0

# リモートのタグを削除
git push origin --delete v1.0.0

# 正しいタグを付け直す
git tag -a v1.0.0 -m "正しいリリース"
git push origin v1.0.0

まとめ

GitHubのブランチとバージョン管理について、基本から実践まで解説してきました。重要なポイントを改めて整理します。

3つの要素の役割

• mainブランチ：プロジェクトの安定版を管理する「本番環境」
• ブランチ：新機能開発やバグ修正を行う「作業環境」
• タグ/Release：特定のバージョンを記録する「アーカイブ」

安全な開発フローの基本

1. 常にブランチを作成してから作業を始める
2. こまめにコミットして進捗を記録する
3. プルリクエストでレビューを受ける
4. マージ後は適切なタグを付ける

初心者が意識すべきこと

• 失敗を恐れずにブランチで実験する
• わかりやすい命名規則を守る
• チームや将来の自分のために記録を残す
• 定期的にmainブランチを最新に保つ

これらの基本を押さえておけば、個人開発でもチーム開発でも、安心してGitHubを活用できるようになります。最初は慣れないかもしれませんが、実際に手を動かしながら少しずつ理解を深めていきましょう。

GitHubの使い方に慣れてくると、コードの管理が格段に楽になり、開発の効率も向上します。この記事で学んだ内容を実践に活かして、より良い開発体験を手に入れてください。頑張ってください！

関連記事:こちらも読まれています！

いまさら聞けない「GitHub」とは？利用メリットから活用法までをわかりやすく解説 【図解あり】DNSレコードでのドメイン所有権の確認メッセージが表示されたら（グーグルサーチコンソールでのドメインプロパティ設定） YouTubeヤラセde炎上 記事を購読してくれているユーザー層をあぶり出したいときにはどうしたらいいのか やりたいことがあるのに作業が進まないときはどうしたらいいの？ .htaccessで失敗しない！初心者向けドメイン移行・リダイレクトの実践～SEOを損なわない旧ドメインから新ドメインへの安全な引っ越し LINEの誤送信取り消し機能が実装されて相手端末にはどのような表示になるのか試してみた