【Git】ブランチ名を変更する方法|branch -m・4ステップ改名・master→main移行まで完全ガイド

【Git】ブランチ名を変更する方法 Git

ブランチ名を作成時にtypoしてしまった、命名規則が途中で変わってfeat-xxxからfeature/xxxに揃えたい、あるいはmasterからmainへプロジェクト全体で移行したい——ブランチの改名は現場でそれなりに発生する作業です。ローカルだけならgit branch -m一発で済みますが、既にpush済みのブランチや複数人で共有しているブランチを改名する場合は、リモート削除・追跡先の付け替え・チームメンバーへの周知までセットで行う必要があります。

この記事では、Gitのブランチ名変更を体系的にまとめます。ローカル単独での改名、現在ブランチ/別ブランチの違い、リモートを含めた正しい改名フロー、デフォルトブランチ(main)改名の特別手順、他メンバーが同期する手順まで、事故を起こさないための実践ガイドです。

この記事で学べること

  • git branch -m(rename)と-M(force rename)の違い
  • 現在チェックアウト中/別ブランチを改名する手順の違い
  • リモートを含めた4ステップ改名フロー
  • デフォルトブランチ(main/master)改名の特別な扱い
  • upstream追跡先(--set-upstream-to)の正しい設定方法
  • 名前衝突・push拒否・他メンバーの同期ミスといった落とし穴への対処
  • 改名が必要になる代表ケース(typo・命名規則移行・default移行)
スポンサーリンク

改名の場面は3つに分かれる

ブランチ名変更はどこまで影響させるかで手順が変わります。最初に自分の状況がどれかを確認しましょう。

場面 必要な操作
ローカルだけに存在するブランチの改名 git branch -m1発
既にpush済みのブランチの改名 ローカル改名→新名でpush→古いリモート削除→upstream付け替え
デフォルトブランチ(main等)の改名 上記に加えGitHub等の管理画面でdefault branch切替が必要

ポイント:未pushの個人ブランチなら気軽に改名できますが、リモートに出ているブランチはチームに影響する破壊的操作になります。共有中のブランチは本当に改名が必要か、PR番号やリンクが変わる影響を含めて判断しましょう。

git branch -m と -M の違い

ブランチ改名の中核コマンドはgit branch -m(move/rename)です。-m(小文字)は同名ブランチが存在したら拒否、-M(大文字)は強制上書き。通常は小文字が安全です。

基本的な使い方
# 現在ブランチを改名
git branch -m new-branch-name

# 別ブランチを指定して改名(チェックアウト不要)
git branch -m old-name new-name

# 既に new-name が存在する場合、-m ではエラー
# fatal: A branch named 'new-name' already exists.

# 強制上書き(既存ブランチを置き換える)
git branch -M new-name
# または
git branch -M old-name new-name

禁止事項:-M(大文字)は既存ブランチを問答無用で上書きします。同名の作業中ブランチがあった場合、そのコミットが失われる可能性があります。-Mは「main→master反転」のような特殊ケースと、消えていい実験ブランチを潰すとき以外は使わない方が安全です。

場面①:ローカルブランチだけを改名

まだpushしていないブランチなら、git branch -m一発で完了します。リモートへの影響もチームへの周知も不要です。

ローカル単独の改名
# 現在ブランチを改名(typo修正など)
git branch -m feature/login

# 確認
git branch --show-current
# → feature/login

# 別ブランチを改名(チェックアウトせずに)
git branch -m old-feature new-feature

# 全ブランチ一覧で確認
git branch

ポイント:-mのあとに引数を1つだけ渡すと「現在ブランチを改名」、2つ渡すと「(現在いなくても)指定ブランチを改名」と挙動が変わります。

場面②:push済みブランチを完全に改名する4ステップ

既にリモートに存在するブランチは、ローカルを改名するだけでは不十分です。リモートの旧ブランチはそのまま残り、古い追跡情報(upstream)も存在しないブランチを指したままになってしまいます。以下の4ステップで完全に改名しましょう。

push済みブランチの完全改名
# STEP 1: ローカルを改名
git branch -m old-name new-name

# STEP 2: 新しい名前でpush(upstreamも同時設定)
git push origin -u new-name

# STEP 3: リモートの古いブランチを削除
git push origin --delete old-name

# STEP 4: リモート追跡情報を整理
git fetch --prune

# 状態確認
git branch -vv
# → new-name [origin/new-name] になっていればOK

順序を間違えると起きる問題

注意:上記のSTEP 2と3の順序を逆にしないでください。「古いブランチを先に削除 → 新しいブランチをpush」では、古いブランチを参照していたPRが閉じてしまう場合があります(GitHubの仕様)。必ず「新しいブランチをpush → 古いブランチを削除」の順序で進めましょう。

単一コマンドでまとめる

ワンライナーで一括処理
# 旧ブランチ名と新ブランチ名を変数に
OLD=old-name
NEW=new-name

# 一連の処理
git branch -m "$OLD" "$NEW" && \
  git push origin -u "$NEW" && \
  git push origin --delete "$OLD" && \
  git fetch --prune

改名後にgit pushが拒否される場合(upstream不一致など)の対処はブランチ名を変更したらpushできなくなったときの対処法に詳しい手順があります。

改名がPR(プルリクエスト)に与える影響

push済みブランチからPRが作成されている場合、改名による影響に注意が必要です。

GitHubでの挙動

  • 新ブランチをpushしても、古いブランチ名のPRは自動で新名に切り替わらない
  • 古いリモートブランチを削除するとPRは閉じることがある
  • ベースブランチ(merge先)の改名はGitHubが自動追従する場合が多い
  • リンクの安定性を保ちたいなら、PR作成前に命名を確定させるのが原則

PRが開いている状態で改名する場合の手順

PR維持で改名する現実的な流れ
# STEP 1: 新ブランチ名でpushして新しいPRを先に作る
git branch -m old-name new-name
git push origin -u new-name

# STEP 2: 古いPRに「renameしたので #xxx で続き」とコメントしてクローズ
# STEP 3: 新PRで議論・レビューを続行

# STEP 4: 全てマージされた後、古いリモートブランチを削除
git push origin --delete old-name
git fetch --prune

ポイント:PRのURLやレビューコメントの継続性を重視する環境では、安易に改名せずPR本体のリネーム(タイトル変更)だけで済ませるのも選択肢です。ブランチ名とPR title は別物なので、PR titleを修正してもブランチ名は変わりません。

デフォルトブランチ(master→main)の改名

プロジェクト全体でmasterからmainに移行する場合は、通常の改名に加えてリモート側のデフォルトブランチ設定の切り替えが必要です。CI・デプロイ・PR作成ベースなどに影響するため、慎重に進めましょう。

master→main の移行手順
# STEP 1: ローカルを改名
git branch -m master main

# STEP 2: 新ブランチをpush(upstream設定)
git push origin -u main

# STEP 3: GitHub/GitLab管理画面でdefault branchをmainに変更
# GitHub: Settings → Branches → Default branch → 切替ボタン
# GitLab: Settings → Repository → Default branch

# STEP 4: リモートのmaster を削除
git push origin --delete master

# STEP 5: origin/HEAD を新しいdefault branchに設定
git remote set-head origin main
# または自動検出
git remote set-head origin --auto

# STEP 6: ローカル追跡情報を整理
git fetch --prune

禁止事項:default branchの切り替え前にgit push origin --delete masterを実行すると、GitHubが削除を拒否します。(保護ブランチ設定がある場合はさらに拒否される)必ず「default branch切り替え→旧ブランチ削除」の順で進めてください。

チーム通知必須:default branchの改名はCI設定・PRテンプレート・デプロイフック・ブランチ保護ルール・外部サービスのwebhook等に影響します。移行前にチーム全員と関連システムを洗い出し、切替日を決めてから実施しましょう。GitHubの「Rename branch」機能を使うと、多くの連携が自動調整されるのでおすすめです。

他メンバーが同期する手順

各メンバー側で実行するコマンド
# 全リモート情報の最新化
git fetch --all --prune

# 古いmasterをローカルから削除
git branch -m master main-local-backup   # 念のため別名に退避(任意)
# または単純に削除
git branch -d master

# origin/HEAD を更新
git remote set-head origin --auto

# mainをローカルに作成(upstream設定)
git switch main

# 既にmainブランチが古い参照で残っている場合
git branch --set-upstream-to=origin/main main

改名後のupstream(追跡先)設定

改名後はローカルブランチが指すリモート追跡先が古いままになっていることがあります。git pushno upstream警告が出る場合はここが原因です。

upstream の確認と設定
# 現在のupstream確認
git branch -vv
# → * main 12ab34cd [origin/main] Commit message
# [] 内に追跡先が表示される。消えていたり古い名前なら設定が必要

# 新しいupstreamを設定
git branch --set-upstream-to=origin/new-name
# または短縮形
git branch -u origin/new-name

# 初回pushと同時に設定する場合
git push origin -u new-name

# upstream情報だけを解除(追跡関係を解除したい場合)
git branch --unset-upstream

upstream概念の詳細はoriginとupstreamの違いと使い分け完全ガイド、リモートブランチ確認はリモートブランチを確認する方法を参照してください。

実践シナリオ

シナリオ① typoしたローカルブランチを直す

未pushブランチの修正
# 作業を始めたがブランチ名がtypo
git branch --show-current
# → feture/login   ← ミス

# 改名
git branch -m feature/login

# 確認
git branch --show-current
# → feature/login

シナリオ② 命名規則移行(feat-xxx → feature/xxx)

複数ブランチの一括リネーム
# 対象を確認
git branch | grep "^  feat-"

# パターン置換で一括改名(bash)
for branch in $(git branch | grep "^  feat-" | tr -d ' '); do
  new_name=$(echo "$branch" | sed 's|feat-|feature/|')
  git branch -m "$branch" "$new_name"
  echo "renamed: $branch -> $new_name"
done

# 未pushブランチのみを想定。push済みは個別に上記4ステップを実行

シナリオ③ push済みの個人ブランチを改名

共有前の個人ブランチ改名
# 4ステップを実行
git branch -m feature/wrong-name feature/correct-name
git push origin -u feature/correct-name
git push origin --delete feature/wrong-name
git fetch --prune

# 他メンバーがまだpullしていないことを確認(Slack/PRで周知)
# PRがあれば新ブランチで作り直すか、PRページの「Rename branch」を使う

シナリオ④ GitHubのUIから改名する

GitHub Branches ページのRename機能

  • リポジトリ → Branches → 改名したいブランチの鉛筆アイコンクリック
  • 新しい名前を入力してRename
  • GitHubが既存PRのhead branchを自動追従してくれる
  • webhook・Actions・ブランチ保護も可能な範囲で自動更新
  • チームメンバーはpull時にgit fetch --prune+upstream更新が必要

GUI改名の最大の利点は、PR・CI・webhookへの影響をGitHubが自動でハンドリングしてくれる点です。Default branchの切替もこのUI経由が安全です。

他メンバーが改名に追従する手順

共有ブランチを改名した場合、他メンバーは次のコマンドで追従します。改名を行った人は、このコマンドをSlackやPRに貼って通知するとスムーズです。

他メンバー側の追従コマンド
# 最新情報を取得+削除済みブランチを整理
git fetch --all --prune

# 旧名ブランチが手元にあれば改名
git branch -m old-name new-name

# 新しいupstreamを設定
git branch -u origin/new-name

# 状態確認
git branch -vv
# → new-name [origin/new-name] になっていればOK

# default branchが変わった場合
git remote set-head origin --auto

ポイント:改名を行った人は改名後のコマンドセットをドキュメント化してチーム通知すると混乱が最小化されます。「ブランチ名を xxx から yyy に変更しました。各自これを実行してください」と具体的コマンドを添えるのが丁寧な運用です。

やってはいけない落とし穴

ローカル改名だけで終わらせる

push済みブランチをgit branch -mだけ実行しても、リモートには古い名前のブランチが残ります。次回push時にno upstream警告や二重ブランチ状態になり、チームを混乱させます。必ず「ローカル改名→新名push→旧名削除→prune」の4ステップを完遂しましょう。

default branchを切り替える前に旧名を削除する

masterからmainに移行するとき、GitHub側のdefault branch設定を変える前にgit push origin --delete masterを実行すると拒否されます。保護ブランチ設定も相まってpush自体ができないこともあります。必ず「新ブランチpush→GitHub UIでdefault切替→旧ブランチ削除」の順序を守ってください。

-M(大文字)を気軽に使う

-Mは同名ブランチを強制的に上書きします。「まだコミットしていない実験ブランチを上書きしてしまった」という事故が起きるので、基本は-mを使い、衝突時はエラーで気付けるようにしましょう。

共有ブランチ(mainなど)でforce pushと混同する

改名操作自体はforce pushを伴いませんが、デフォルトブランチ切替忘れの状態で「新ブランチをforce pushで上書き」したり、「古いブランチに新内容をforce push」する操作は、他メンバーの環境を破壊します。改名はあくまで「別名の新ブランチを作って古いものを消す」だけで、--force系の操作は本来不要です。

改名を頻繁に行ってPR履歴を混乱させる

レビュー中のPRが紐づいているブランチを改名すると、レビューコメントのコンテキストが追いにくくなる、自動化スクリプトのブランチ名マッチが失敗する、等の副作用があります。PR作成前に命名を確定させるのが一番健全。どうしても改名が必要ならGitHubのBranches UIのRename機能を使い、チーム通知を忘れずに。

よくある質問

Qgit branch -m で改名したらコミット履歴はどうなる?
A保持されます。ブランチ名は「特定コミットへのラベル」なので、ラベルの名前を付け替えているだけです。履歴・コミットSHA・作業内容は変わりません。
Q改名後にgit pushで「no upstream」と言われる
A追跡先が設定されていないか古いままです。git push origin -u new-nameで設定するか、git branch -u origin/new-nameで既存ブランチに付け替えてください。
Q現在ブランチを改名するのにチェックアウトは必要?
A必要ありません。git branch -m old-name new-nameはどのブランチにいても実行できます。引数なしでgit branch -m new-nameの場合は現在ブランチが対象になります。
Qmainからmasterのように元に戻したい
A同じ4ステップを逆方向で実行します:ローカル-m main master→新名push→旧名削除→prune。default branchも切り替えるなら管理画面のデフォルト設定変更が先です。
Q改名後のPRはどうなる?
AGitHubのBranches UI(Rename機能)を使えば既存PRは自動追従します。CLIで改名した場合は、古いPRを閉じて新しいブランチで作り直すのが確実です。通知とレビュー継続性のため、PR作成前に命名を確定させるのが理想です。
Q改名したらpushが拒否される
A保護ブランチ設定・upstream不一致・リモートに同名ブランチがある、などが考えられます。詳細なトラブルシューティングはブランチ名を変更したらpushできなくなったときの対処法を参照してください。
Q他メンバーが古いブランチ名のまま作業を続けてしまった
A改名直前のコミットを共通の祖先として、git switch -c new-name old-nameで新ブランチを作って作業を移動してもらいます。その後git branch -D old-nameで古いローカルブランチを削除すれば復旧できます。

関連記事

まとめ

  • ローカル改名はgit branch -m1発、力技-Mは特殊ケースのみ
  • push済みブランチは4ステップ(ローカル改名→新名push→旧名削除→prune)が必須
  • 新名push→旧名削除の順序を逆にしない(PRが消える)
  • upstream追跡先はgit push -uまたはgit branch -uで設定
  • default branch(master→main)改名は管理画面の切替が先
  • 改名はGitHub UIのRename機能を使うとPR・webhook・Actionsが自動追従
  • チーム共有中は事前通知+追従コマンドの提示がマナー

ブランチ名変更は単純そうで、push済みになると4ステップ・default branchだと管理画面操作と、影響範囲が広がる操作です。「ローカル → push → 旧名削除 → prune」の順序を覚えておけばほとんどのケースは事故なく対応できます。GitHub UIのRename機能やBranches設定をうまく活用し、PR・CI・webhookへの影響を最小化しながら運用しましょう。