ブランチとは Git：初心者が押さえるべき基本概念と実務での使い方

はじめに

ソフトウェア開発において「ブランチ」と聞くと、初めて Git を触る人は戸惑いがちです。ブランチは「枝分かれした開発ライン」のようなイメージを持つと分かりやすく、機能追加や不具合修正、実験的な開発を安全に行うために欠かせません。この記事では、Git におけるブランチの基本概念から、初心者でも試してみやすい実務での使い方、さらにプロジェクト規模に合わせたブランチ戦略までを順を追って解説します。これを読めば「ブランチを使うと何が便利になるのか」「どうやって日々のワークフローに取り入れればいいのか」がイメージできるはずです。

1. ブランチは何なのか？（基本概念）

1-1. ブランチとは？

Git では、レポジトリ（リポジトリ）内に「ブランチ」という単位で履歴を管理します。

• ブランチ は、ある時点のコミット（スナップショット）を基盤にした「独立した履歴の道」のこと。
• つまり、親コミットをもとに分岐した別の作業ラインです。

1-2. なぜブランチが便利なのか

2. ブランチの基本操作

2-1. ブランチ一覧を確認する

git branch           # ローカルブランチ一覧
git branch -a        # ローカル＋リモートブランチ

2-2. ブランチを作成する

# コミット `main` からブランチを作成
git checkout -b feature/new-login
# 既存ブランチからブランチを作成（HEAD 位置も移動）
git checkout -b feature/new-login main

2-3. ブランチを切り替える

git checkout feature/new-login   # ブランチを切り替える
# ディレクトリ内で安全に作業しよう

2-4. ブランチを削除する

# ローカルブランチ削除（未マージでも OK ）
git branch -d feature/old-feature   # -d で安全に削除
# 失敗した場合は -D で強制削除
git branch -D feature/old-feature

# リモートブランチ削除
git push origin --delete feature/old-feature

2-5. ブランチの名前を変更

git branch -m old-name new-name

3. マージとリベース

3-1. マージ（merge）

• マージ は、別ブランチのコミットを現在のブランチに統合する操作です。
• 典型的なフロー: feature → main へのマージ.

git checkout main
git pull origin main
git merge feature/new-login

• マージコミットが作られ、両ブランチの変更を一つにまとめる。

3-2. リベース（rebase）

• リベース は、あるブランチを別ブランチの先頭に「上乗せ」させる操作。
• 歴史が直線的になるため、履歴が整理しやすい。

git checkout feature/new-login
git fetch origin
git rebase origin/main

• コンフリクトが起きた場合は git status で確認し、手動解決後 git add → git rebase --continue。

3-3. マージ vs リベース

4. コンフリクトをうまく解消するコツ

1. 小さめのコミット：大きな変更を小さく分割し、早めにマージする。
2. 頻繁に同期：git fetch && git rebase master を定期的に実行。
3. 明確なコメント：コンフリクト箇所を明記したコメント付きコミットで後から確認しやすく。
4. Git GUI ツール：VSCode の Git 拡張、Sourcetree、GitKraken などで視覚的に解消。

5. ブランチ戦略

大きさやチーム構成に応じて最適なブランチ戦略を選びます。以下は代表的なパターンです。

5-1. GitFlow

• 特徴：master はリリース済み状態、develop は開発状態を管理。
• ブランチ | 用途 |
  |—|—|
  | master | 本番環境 |
  | develop | 開発ベース |
  | feature/* | 新機能 |
  | release/* | リリース準備 |
  | hotfix/* | 本番の緊急修正 |

使い方サンプル

# 仕様に応じてブランチを作る
git checkout develop
git checkout -b feature/login
# 開発...
git checkout develop
git merge --no-ff feature/login
git checkout master
git merge --no-ff develop

• 長期プロジェクトや大規模リポジトリで有効。

5-2. GitHub Flow

• 特徴：短期間でのデプロイを前提。master は常にデプロイ可。
• ブランチ：feature/* または bugfix/* → PR → マージ。
• PR（Pull Request）でレビュー・CIが実行される。

使い方サンプル

# 新しい機能
git checkout -b feature/chatbot
# コミット...
git push -u origin feature/chatbot
# PR を作成し、レビューを承認 → master にマージ

• 小規模チームやオープンソースプロジェクトで最初に触れる戦略。

5-3. Trunk-Based Development

• 特徴：1つのメインブランチ（main）だけを使い、頻繁にマージ・リリース。
• ブランチ：短期的な作業ブランチのみ。
• メリット：マージコンフリクトが少ない。
• 主な手法：Feature Toggle（機能フラグ）で実装途中を切り替え。

使い方サンプル

git checkout -b feature/notification
# 50 行で完了
git commit -am "Add notification feature"
git push -u origin feature/notification
# フィーチャートグルをオフにし、実装が不完全
git checkout main
git merge feature/notification

• 速度と安定性を両立したい場合に推奨。

6. 実務でのブランチ運用のポイント

7. ブランチに関するよくある疑問

Q1: 「ブランチで作業しているときに main に変更が入ったらどうすればいい？」

A: git fetch → git rebase origin/main でリベースし、コンフリクトを解消。リベース後は git push --force-with-lease。

Q2: 「マージ競合が頻繁に起きる理由は？」

A: 開発ブランチが長期間開いていると、同じファイルを複数人が変更すると競合が発生しやすくなる。短く切るか、feature/* を早めにマージする。

Q3: 「ブランチを完全に削除したい」

A: git branch -d でローカル、git push origin --delete ブランチ名 でリモート。ローカルのリファレンスも削除される。

Q4: 「リベースして履歴を整形したけど、みんなに影響が出るの？」

A: 共有ブランチ（main など）で公開済みの変更をリベースすると、他の開発者の履歴がズレるため避ける。ローカルや非公開ブランチでのみリベース。

8. まとめ

• ブランチは作業を安全に分離し、チームの協調をスムーズにする
• 基本操作（branch, checkout, merge, rebase）は覚えておくと、日々の開発が楽になる
• 大きなプロジェクトでは GitFlow、短いリリースサイクルなら GitHub Flow、スピード重視なら Trunk-Based Development を検討
• ブランチ運用は「ルール・自動化・レビュー」の三本柱で安定性と品質を保つ

Git のブランチをただの「分岐点」ではなく、「チーム全員が安心して変更を積み上げられる管理構造」と捉えると、さらに便利な工具として使いこなせるようになります。ぜひ、今回紹介したコマンドと戦略を踏まえて、日常業務にブランチを組み込んでみてください。