ブランチ名を作成時に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つに分かれる
ブランチ名変更はどこまで影響させるかで手順が変わります。最初に自分の状況がどれかを確認しましょう。
ポイント:未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ステップで完全に改名しましょう。
# 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が開いている状態で改名する場合の手順
# 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作成ベースなどに影響するため、慎重に進めましょう。
# 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 pushでno 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したローカルブランチを直す
# 作業を始めたがブランチ名が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機能を使い、チーム通知を忘れずに。
よくある質問
git push origin -u new-nameで設定するか、git branch -u origin/new-nameで既存ブランチに付け替えてください。git branch -m old-name new-nameはどのブランチにいても実行できます。引数なしでgit branch -m new-nameの場合は現在ブランチが対象になります。-m main master→新名push→旧名削除→prune。default branchも切り替えるなら管理画面のデフォルト設定変更が先です。git switch -c new-name old-nameで新ブランチを作って作業を移動してもらいます。その後git branch -D old-nameで古いローカルブランチを削除すれば復旧できます。関連記事
- 【Git】ブランチ名を変更したらpushできなくなったときの対処法 — 改名後のpushエラー専門解説
- 【Git】ブランチを削除する方法 — 旧ブランチを消す詳細手順
- 【Git】新しいブランチを作成する基本的な手順 — ブランチ作成の基礎
- 【Git】リモートブランチを確認する方法 — 改名後の状態確認
- 【Git】originとupstreamの違いと使い分け完全ガイド — upstream概念の深掘り
- 【Git】リモートブランチを削除しても残ってしまうときの原因と解決方法 — pruneの重要性
- Gitで過去のコミットから新しいブランチを作り作業をやり直す方法 — 改名より新ブランチが適切なケース
- 【Git】よく使うgitコマンドまとめ — 日常操作の早見表
まとめ
- ローカル改名は
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への影響を最小化しながら運用しましょう。

