git branchコマンドの使い方｜作成・切り替え・削除を完全解説

チーム開発で「このブランチって何のためにあるんだっけ？」「古いブランチが溜まって整理したい」といった悩みを抱えていませんか。git branchはGitでブランチを管理するための基本コマンドですが、オプションが多く使いこなせていない方も多いのではないでしょうか。

この記事では、git branchの基本操作から実践的なブランチ戦略、そしてチーム開発で役立つベストプラクティスまで詳しく解説します。ブランチ管理をマスターして、効率的な開発ワークフローを実現しましょう。

git branchの概要

git branchは、Gitでブランチの一覧表示、作成、削除、名前変更を行うコマンドです。ブランチとはコミットへのポインタのことで、非常に軽量な操作で独立した開発ラインを作成できます。

ブランチを使う最大のメリットは、メインコードベースから隔離された環境で安全に作業できることです。新機能の開発やバグ修正を行う際、メインブランチに影響を与えることなく実験的な変更を試すことができます。作業が完了したらマージして統合し、不要になったブランチは削除するというサイクルで開発を進めていきます。

なお、Git 2.23以降では、ブランチの切り替えにgit switchコマンドが追加されました。従来のgit checkoutも引き続き使用できますが、目的が明確なgit switchの使用が推奨されています。

ブランチの一覧表示

まずは現在のブランチ状態を確認する方法から見ていきましょう。オプションなしでgit branchを実行すると、ローカルブランチの一覧が表示されます。

# ローカルブランチを表示
git branch
# 出力例:
#   develop
# * main
#   feature/user-auth

# 現在のブランチ名のみを表示
git branch --show-current
# 出力: main

現在チェックアウトしているブランチには*マークが付きます。リモートリポジトリのブランチも確認したい場合は、-aまたは-rオプションを使用します。

# すべてのブランチを表示（ローカル + リモート）
git branch -a
# 出力例:
#   develop
# * main
#   feature/user-auth
#   remotes/origin/main
#   remotes/origin/develop

# リモート追跡ブランチのみ表示
git branch -r

さらに詳細な情報を確認したい場合は、-vや-vvオプションが便利です。

# コミットハッシュとメッセージも表示
git branch -v
# 出力例:
#   develop     a1b2c3d 機能追加
# * main        d4e5f6g 初期コミット
#   feature/auth h7i8j9k ログイン機能実装

# アップストリーム情報も表示
git branch -vv
# 出力例:
# * main [origin/main] 初期コミット

ブランチの作成

新しいブランチを作成するには、git branchに続けてブランチ名を指定します。ただし、このコマンドはブランチを作成するだけで、そのブランチには切り替わらない点に注意してください。

# 現在のHEADから新しいブランチを作成（切り替えなし）
git branch feature/new-feature

# ブランチが作成されたか確認
git branch
# 出力:
#   feature/new-feature
# * main

特定のコミットやタグを起点にブランチを作成することもできます。過去のバージョンからホットフィックスブランチを作成する場合などに便利です。

# 特定のコミットから作成
git branch hotfix/urgent-fix abc1234

# タグから作成
git branch release-1.0 v1.0.0

# リモートブランチを追跡するブランチを作成
git branch --track feature/remote-feature origin/feature/remote-feature

ブランチの切り替え

作成したブランチで作業を開始するには、そのブランチに切り替える必要があります。Git 2.23以降ではgit switchコマンドの使用が推奨されています。

# git switch（推奨、Git 2.23+）
git switch feature/new-feature

# git checkout（従来の方法）
git checkout feature/new-feature

ブランチの作成と切り替えを同時に行うこともできます。新しいフィーチャーブランチを開始する際によく使うパターンです。

# git switch で作成と切り替えを同時に
git switch -c feature/another-feature

# git checkout の場合
git checkout -b feature/another-feature

# 特定のコミットを起点にブランチ作成して切り替え
git switch -c hotfix/critical-bug v1.0.0

git checkout と git switch の違い

Git 2.23でgit switchとgit restoreが導入されました。これはgit checkoutが持っていた複数の機能を分離したものです。

git switchを使うメリットは、目的が明確でブランチ操作に特化している点です。誤ってファイルを上書きしてしまうリスクが低く、初心者にも理解しやすいコマンドになっています。ただし、Git 2.23より前のバージョンを使用している環境やスクリプトの互換性が必要な場合は、引き続きgit checkoutを使用してください。

ブランチの削除

作業が完了してマージされたブランチは、定期的に削除して整理することが推奨されます。-dオプションを使用すると、マージ済みのブランチのみ削除できます。

# 安全な削除（マージ済みの場合のみ）
git branch -d feature/completed-feature

# 複数ブランチを一度に削除
git branch -d feature/a feature/b feature/c

マージされていないブランチを削除しようとすると、Gitは警告を出して削除を拒否します。変更を破棄してでも削除したい場合は、-Dオプション（大文字）で強制削除できます。

# 強制削除（マージ状態を無視、変更は失われる）
git branch -D feature/abandoned-work

リモートブランチの削除

リモートリポジトリのブランチを削除する場合は、git pushコマンドを使用します。

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

# 古いリモート追跡ブランチの参照をクリーンアップ
git fetch --prune
# または
git remote prune origin

git fetch --pruneを実行すると、リモートで既に削除されているブランチの追跡参照がローカルからも削除されます。定期的に実行して、ローカルの参照を最新の状態に保つことをお勧めします。

ブランチの名前変更

ブランチ名を間違えた場合や、命名規則を統一したい場合は、-mオプションで名前を変更できます。

# 現在のブランチを名前変更
git branch -m new-name

# 特定のブランチを名前変更
git branch -m old-name new-name

# 強制的に名前変更（新しい名前が既に存在する場合）
git branch -M old-name new-name

リモートブランチの名前を変更する場合は、少し手順が複雑になります。リモートブランチは直接名前変更できないため、新しい名前でプッシュしてから古いブランチを削除する必要があります。

# 1. ローカルブランチを名前変更
git branch -m old-feature new-feature

# 2. 新しい名前でリモートにプッシュ
git push origin new-feature

# 3. 古いリモートブランチを削除
git push origin --delete old-feature

# 4. アップストリームを再設定
git branch -u origin/new-feature new-feature

この変更を行った場合、チームメンバーにも周知して、各自のローカル環境で追跡設定を更新してもらう必要があります。

便利なブランチ表示オプション

大規模なプロジェクトではブランチが増えがちです。条件を指定してブランチを絞り込む方法を覚えておくと便利です。

# マージ済みブランチのみ表示（削除候補の確認に便利）
git branch --merged main

# 未マージブランチのみ表示
git branch --no-merged main

# 特定のコミットを含むブランチを表示
git branch --contains abc1234

# パターンでフィルタリング
git branch --list 'feature/*'
git branch -l 'release-*'

マージ済みブランチを一括削除するワンライナーも便利です。ただし、mainブランチを誤って削除しないようgrep -vで除外しています。

# マージ済みブランチを一括削除（main、developは除外）
git branch --merged main | grep -v -E "(main|develop)" | xargs git branch -d

ブランチ命名規則

チーム開発では、一貫した命名規則を採用することでブランチの目的が一目でわかるようになります。

推奨プレフィックス

命名のポイント

ブランチ名には小文字とハイフンを使用し、クロスプラットフォームでの問題を避けます。プロジェクト管理ツールのチケット番号を含めると、作業内容の追跡が容易になります。

# 良い例
feature/AUTH-42-oauth-integration
bugfix/BUG-123-fix-null-pointer
hotfix/SEC-99-patch-vulnerability

# 避けるべき例
Feature/UserAuth      # 大文字は避ける
feature_user_auth     # アンダースコアよりハイフン推奨
newfeature            # 目的がわかりにくい

ブランチ戦略の選択

チームの規模やリリース頻度に応じて、適切なブランチ戦略を選択することが重要です。代表的な3つの戦略を紹介します。

Gitflow

伝統的なブランチ戦略で、main、develop、feature、release、hotfixの複数ブランチを使い分けます。リリースサイクルが長いプロジェクトや、複数バージョンを並行してメンテナンスする必要がある場合に適しています。ただし、ブランチ構造が複雑になりがちで、現在はよりシンプルな戦略に人気が移行しています。

Trunk-Based Development

全開発者が単一のメインブランチ（trunk）に頻繁にコミットするシンプルな戦略です。フィーチャーブランチは作成しても1日以内にマージすることを推奨します。CI/CDとの相性が良く、Googleなどの大規模組織でも採用されています。モダンなDevOps実践では最も推奨される戦略です。

GitHub Flow

GitHubが提唱するシンプルなワークフローで、mainブランチとフィーチャーブランチのみを使用します。PRによるコードレビューを経てmainに直接マージし、mainは常にデプロイ可能な状態を維持します。小〜中規模チームや頻繁にリリースを行うプロジェクトに最適です。

戦略の選択指針

迷った場合は、GitHub FlowかTrunk-Based Developmentから始めることをお勧めします。複雑なワークフローは必要になってから導入しても遅くありません。

よくある問題と解決策

現在のブランチを削除できない

作業中のブランチは削除できません。別のブランチに切り替えてから削除してください。

# エラー: cannot delete branch 'feature' used by worktree
# 解決: 別のブランチに切り替えてから削除
git switch main
git branch -d feature

未マージブランチの削除警告

マージされていないブランチを削除しようとすると警告が表示されます。本当に不要な場合は強制削除を使用しますが、変更内容を確認してから実行してください。

# エラー: The branch 'feature' is not fully merged.
# 解決1: マージしてから削除
git merge feature
git branch -d feature

# 解決2: 強制削除（変更は失われる）
git branch -D feature

間違ったブランチで作業してしまった

変更をスタッシュして正しいブランチに移動するか、新しいブランチを作成します。

# 変更をスタッシュして正しいブランチへ
git stash
git switch correct-branch
git stash pop

# または新しいブランチを作成して変更を持っていく
git switch -c new-feature

ベストプラクティス

効率的なブランチ管理のために、以下のプラクティスを意識しましょう。

フィーチャーブランチは可能な限り短命に保ちます。理想的には1日以内、長くても数日以内にマージまたはクローズすることで、マージコンフリクトのリスクを大幅に減らせます。長期間放置されたブランチは、メインブランチとの差分が大きくなり、統合が困難になります。

作業中も定期的にメインブランチの変更を取り込みましょう。git rebaseまたはgit mergeでメインブランチと同期することで、最終的なマージをスムーズに行えます。

# rebaseで同期（履歴がきれいになる）
git fetch origin
git rebase origin/main

# mergeで同期（マージコミットが残る）
git fetch origin
git merge origin/main

マージ済みのブランチは定期的に削除して、リポジトリを整理しましょう。ブランチが増えすぎると、必要なブランチを見つけるのが困難になります。

最後に、直接メインブランチにプッシュするのではなく、PRを通じてコードレビューを実施することをお勧めします。品質の維持だけでなく、チーム内での知識共有にも役立ちます。

よくある質問

git branch と git checkout -b の違いは何ですか？

git branch <name>はブランチを作成するだけで、切り替えは行いません。git checkout -b <name>（またはgit switch -c <name>）はブランチの作成と切り替えを同時に行います。新しいブランチで作業を開始する場合は後者が便利です。

リモートブランチを直接チェックアウトできますか？

git switchまたはgit checkoutでリモートブランチ名を指定すると、自動的にローカルの追跡ブランチが作成されます。git switch feature/remoteとするだけで、origin/feature/remoteを追跡するローカルブランチが作成されて切り替わります。

削除したブランチを復元できますか？

最近削除したブランチはgit reflogで見つけて復元できる場合があります。git reflogでコミットハッシュを確認し、git branch <name> <commit-hash>で復元できます。ただし、reflogは一定期間で削除されるため、早めの対応が必要です。

まとめ

git branchはGitでのブランチ管理に欠かせないコマンドです。基本的な操作として、git branchで一覧表示、git branch <name>で作成、git branch -dで削除、git branch -mで名前変更ができます。

ブランチの切り替えには、Git 2.23以降で追加されたgit switchの使用が推奨されています。git checkoutよりも目的が明確で、誤操作のリスクを減らせます。

チーム開発では、一貫した命名規則を採用し、プロジェクトに適したブランチ戦略を選択することが重要です。Trunk-Based DevelopmentやGitHub Flowなど、シンプルな戦略から始めて、必要に応じて調整していくアプローチがお勧めです。

まずは基本操作をマスターし、日常的にブランチを活用して安全な開発ワークフローを構築していきましょう。

参考リンク

Git公式ドキュメント – git-branch

Git Branching – Atlassian Git Tutorial

Git switch vs Git checkout | Graphite

Trunk-based Development | Atlassian