【Git】ブランチ名変更後にpushできないときの6パターン診断と対処法|upstream・default branch・PR追従まで完全ガイド

【Git】ブランチ名を変更したらpushできなくなったときの対処法 Git

git branch -m old newでブランチ名を変更した直後にgit pushが失敗する——このエラーは、ローカルの改名とリモートの状態が噛み合っていないことが原因です。典型的には次のような出力が出ます。

よくあるエラー
$ git push
fatal: The current branch new-name has no upstream branch.
To push the current branch and set the remote as upstream, use
    git push --set-upstream origin new-name

# あるいは
 ! [rejected]        new-name -> new-name (non-fast-forward)

この記事では、ブランチ名変更後にpushできなくなる6つの典型パターンと状況別の正しいリカバリ手順をまとめます。旧リモートブランチの削除・upstream付け替え・PR影響の扱い・保護ブランチ対応まで、改名作業を安全に完結させるための実践ガイドです。

この記事で学べること

  • 改名後にpushできない6パターンと対処
  • upstream(追跡先)未設定/誤設定の直し方
  • リモートにもブランチ名を反映する正しい手順
  • 既に同名ブランチがリモートに存在する場合の扱い
  • 保護ブランチ/デフォルトブランチの改名手続き
  • PR/webhook/Actionsへの影響と対応
  • GitHub UIのRename機能を使った安全な改名
スポンサーリンク

6つの典型パターン

改名後のpushエラーは原因ごとに手順が違います。エラーメッセージから自分のケースを特定しましょう。

パターン 特徴的なエラー 対処
① upstream未設定 no upstream branch push -u origin new-name
② リモートに同名で中身違い non-fast-forward rebase origin/new-name
③ 旧ブランチがリモートに残存 旧名も表示され混乱 push --delete old-name
④ 保護ブランチ protected branch PR経由/設定変更依頼
⑤ デフォルトブランチ改名 旧default削除不可 管理画面で先に切替
⑥ リモートで先に改名された 古い追跡先が残る ローカルも改名+追跡先変更

ポイント:最多は①upstream未設定。改名したブランチはリモートとの紐付けが切れているので、push -u origin new-nameで初回pushと同時に紐付け直す必要があります。エラーメッセージが出す--set-upstreamのヒントをそのまま使えば解決することがほとんどです。

STEP 0:状況を診断する

状態確認コマンド
# 現在のブランチと追跡情報を確認
git branch --show-current
git branch -vv
# 出力例:
# * new-name  abc1234 [origin/old-name: gone] commit msg
#   ↑ 追跡先が「古い名前」で残っている状態

# リモートの実際の状態
git fetch --prune
git ls-remote --heads origin

# upstream参照を直接確認
git rev-parse --abbrev-ref --symbolic-full-name @{u}
# → 追跡先が無ければエラーになる

# 改名前後の差を確認(refログ)
git reflog --date=iso -20

エラー別の読み方

  • no upstream branch → ①
  • non-fast-forward → ②(リモートに同名で別履歴)
  • protected branch hook declined → ④
  • refusing to delete the current branch → ⑤
  • gone表記 → ⑥(追跡先が消えた)

ケース①:upstream未設定(最頻出)

ローカルをgit branch -mで改名した直後に、そのままgit pushするとupstreamが無いのでエラーになります。新名で初回push+upstream設定が必要です。

upstream設定+push
# ローカル改名(既にやっていればスキップ)
git branch -m old-name new-name

# 新名で初回push(-uでupstream同時設定)
git push -u origin new-name

# 出力: Branch 'new-name' set up to track remote branch 'new-name' from 'origin'.

# 以降は通常のpushでOK
git push

autoSetupRemoteで自動化

Git 2.37以降はgit config --global push.autoSetupRemote trueで初回push時に-uを自動付与できます。設定しておけば「upstream忘れ」の事故が激減します。

upstream概念の詳細はoriginとupstreamの違いと使い分け完全ガイドを参照。

ケース②:リモートに同名ブランチが既にあって履歴がズレている

「偶然、同僚がnew-nameというブランチを作っていた」「以前自分がpushした後削除していなかった」など、リモートに同名ブランチが残っていて履歴が分岐している場合、non-fast-forwardでpushが拒否されます。

統合してからpush
# 最新情報取得
git fetch --prune

# リモートの履歴を取り込み(統合)
git rebase origin/new-name
# conflictが出たら解消→continue

# push
git push -u origin new-name
どうしても自分の履歴で置き換えたい(個人ブランチ限定)
# 自分が先にそのブランチを作っていて、もう他で使ってなければ
git push --force-with-lease origin new-name

注意:--force-with-leaseは他メンバーが作業中でないことを確認してから使ってください。共有ブランチや他メンバーの作業ブランチと名前衝突していた場合、上書きしてしまうと相手の作業が失われます。詳しくは“non-fast-forward”で拒否されたときの解決方法を参照。

ケース③:リモートに旧ブランチが残っている

新名でpushできても、リモートには旧名のブランチが残ったままです。放置するとチームメンバーが旧名にpush/レビュー依頼してしまう混乱の元。旧リモートブランチを削除しましょう。

旧リモートブランチを削除
# 新名のpushが済んでいる前提で

# 旧リモートブランチを削除
git push origin --delete old-name
# 短縮形
git push origin :old-name

# リモート情報を掃除
git fetch --prune

# 確認:new-nameだけになった
git ls-remote --heads origin | grep -E "old-name|new-name"

正しい4ステップ改名フロー

  1. ローカル改名:git branch -m old-name new-name
  2. 新名でpush+upstream設定:git push -u origin new-name
  3. 旧リモート削除:git push origin --delete old-name
  4. prune整理:git fetch --prune

ブランチ改名の詳細フローはブランチ名を変更する方法を参照してください。

ケース④:保護ブランチで拒否

main/developなど保護ブランチは直接pushや削除が禁止されている場合が多いです。改名しようとしても旧名削除で拒否されることがあります。

保護ブランチのエラー例
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Cannot delete a protected branch.
 ! [remote rejected] main (protected branch hook declined)

対処

  • 保護ブランチ(main/develop等)は一般メンバーは改名不可
  • 管理者権限で保護ルールを一時解除 → 改名 → 再有効化
  • GitHubのRename機能を使うとdefault branch含めて自動追従
  • CIの必須チェック・レビュー要件も一度外すと楽

ケース⑤:デフォルトブランチ(master→main等)の改名

デフォルトブランチは特別扱いで、管理画面で切り替える前に旧名削除しようとすると拒否されます。正しい順序でないとpushも削除も通らないので要注意。

master→main 正しい順序
# STEP 1: ローカル改名
git branch -m master main

# STEP 2: 新名でpush
git push -u origin main

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

# STEP 4: 旧 master を削除(default切替後は通る)
git push origin --delete master

# STEP 5: origin/HEAD も更新
git remote set-head origin main
# または自動
git remote set-head origin --auto

# STEP 6: prune整理
git fetch --prune

注意:デフォルトブランチ改名はCI/webhook/PR base/外部ツール連携に大きく影響します。GitHubのRename branch機能を使うと多くの連携が自動追従するので、CLIでの手作業より安全です。詳細はブランチ名を変更する方法「remote HEAD refers to nonexistent ref」警告の対処法を参照。

ケース⑥:リモートで先に改名された(自分のupstreamがgone)

他メンバーや管理者がリモート側でブランチ改名した場合、ローカルの追跡先は古いまま。git branch -vv[origin/old-name: gone]と表示されるのが目印です。

ローカル側も追従する
# 最新リモート情報を取得
git fetch --prune

# 自分のローカルブランチを新名に改名
git branch -m old-name new-name

# 新しい追跡先を設定
git branch --set-upstream-to=origin/new-name
# または
git branch -u origin/new-name

# 確認
git branch -vv
# * new-name [origin/new-name] ...

リモートが削除されてgoneになるケース全般はリモートブランチを削除しても残ってしまうときの原因と解決方法を参照。

改名がPR/webhook/Actionsに与える影響

CLIで改名しただけではGitHub等の関連機能は追従しません。影響範囲を把握しておきましょう。

連動する/しない対象

  • PR(プルリクエスト):CLIで改名すると古いPRは紐付けが切れる/クローズされる。GitHub Rename機能を使えば自動追従
  • GitHub Actionson: pushのbranches指定を見直す必要あり
  • webhook:branch名を含むフィルタ設定を更新
  • Branch protection rules:Rename機能を使えば自動更新される
  • 外部サービス(Vercel・Netlify・Heroku等):通常は自動追従するが要確認
  • CODEOWNERS:ブランチ名は関係ないので影響なし

GitHubのBranches UIで改名(推奨)

ポイント:GitHubのリポジトリ → Branches → 対象ブランチの鉛筆アイコン → 新名入力。この操作を行うと、関連するPR・Branch protection・webhook・Actions等が自動でリネームに追従します。CLIで手作業するより圧倒的に安全。クライアント側はgit fetch --prunegit branch -m+upstream再設定で追従。

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

共有ブランチを改名した場合、チームメンバー全員が次の手順で追従する必要があります。改名担当者はこの手順をドキュメントとして共有しましょう。

各メンバー側で実行する同期コマンド
# 最新情報取得+削除済みを整理
git fetch --all --prune

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

# 新しい追跡先を設定
git branch -u origin/new-name

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

# default branch変更があればorigin/HEADも更新
git remote set-head origin --auto

実践シナリオ

シナリオ① typoのリカバリ

初期時に気づいて改名
git branch -m feat-login feature/login
git push -u origin feature/login
git push origin --delete feat-login
git fetch --prune

シナリオ② リモートに同名ブランチがあって衝突

rebaseで統合
git fetch --prune
git rebase origin/new-name
# conflict解消→continue
git push -u origin new-name

シナリオ③ 自分のブランチがgoneと表示される

upstreamを張り直す
git fetch --prune
git branch -m old-name new-name
git branch -u origin/new-name
git branch -vv   # 確認

シナリオ④ master→main移行(個人リポ)

個人リポでの完全移行
git branch -m master main
git push -u origin main

# GitHub管理画面でdefault branch変更

git push origin --delete master
git remote set-head origin --auto
git fetch --prune

予防:改名を事故なく行う運用

改名作業のチェックリスト

  • 改名前にチームメンバーに通知(Slack/PRコメント等)
  • PR作成前に命名を確定(PR作成後の改名は混乱を招く)
  • GitHub Branches UIのRename機能を優先使用
  • CI/webhook/外部連携の追従を事前確認
  • default branchなら管理画面で先に切替
  • push.autoSetupRemote=trueでupstream自動化
  • fetch.prune=trueで追跡情報の自動整理
推奨Git設定
# 自動upstream(Git 2.37+)
git config --global push.autoSetupRemote true

# 自動prune
git config --global fetch.prune true

# 便利なエイリアス
git config --global alias.rename-branch \
  '!f() { git branch -m "$1" "$2" && git push -u origin "$2" && git push origin --delete "$1" && git fetch --prune; }; f'

# 使用例
git rename-branch feat-login feature/login

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

ローカル改名だけで「改名完了」と思い込む

git branch -mはローカルしか変えません。リモートには旧名が残り、upstreamもgoneになっています。必ず新名push→旧名削除→pruneの3点セットで完結させましょう。

旧名を先に削除してからnew-nameをpushしようとする

順序が逆です。「新名push→旧名削除」が正しい順序。順番を逆にするとPRが閉じたり、default branchの場合は削除拒否が発生します。

PRがあるブランチをCLIで改名

オープン中のPRがあるブランチをCLIで改名すると、PRが閉じる/紐付けが切れる可能性があります。GitHubのRename機能を使えばPRが自動追従するので、そちらを優先しましょう。

default branchをRename機能を使わず手作業で変更

GitHubのSettings → Branches → Default branchの切替ボタンを使うのが最も安全。「CLIでmaster→main+旧master削除」の手順だと、PRのbase branchが自動追従しない場合があります。

チーム通知を怠る

共有ブランチ改名は必ず周知しましょう。同僚が古い名前のままpullして[origin/old-name: gone]状態になり、混乱の原因になります。改名コマンドと追従手順をSlack等に貼るのがマナーです。

よくある質問

Qno upstream branch エラーだけ解決したい
Agit push -u origin 現在のブランチ名で1発解決。Git 2.37+ならpush.autoSetupRemote=true設定で初回push時の-u忘れが自動解消します。
Qupstreamがgoneと表示される
A追跡先のリモートブランチが削除/改名されています。git fetch --pruneで整理、必要に応じてgit branch -u origin/新名で追跡先を付け替えましょう。
Q改名したブランチのPRはどうなる?
ACLIで改名した場合、既存PRはclosed/detachedになる可能性があります。GitHubのBranches UIのRename機能を使えば自動追従するので、PRがあるブランチはこちらを優先。
Qmaster→mainにしたらpush –delete masterで拒否される
Adefault branchは削除できません。先にGitHub等の管理画面でdefault branchをmainに切り替えてからgit push origin --delete masterを実行してください。
Q改名後にforce pushは必要?
A基本不要です。「新名push→旧名削除」の2ステップで済みます。リモートに同名ブランチが既にあり履歴が違う場合だけ--force-with-leaseが必要になることがあります。
Q他メンバーはどう追従すれば良い?
Agit fetch --prunegit branch -m old newgit branch -u origin/newの3ステップ。改名担当者がこの手順をチーム共有すれば混乱なし。
Q改名したいが毎回手作業が面倒
AGitエイリアスで一括化できます。rename-branch old newコマンドを自作しておくと「ローカル改名→push→旧削除→prune」を1行で実行できます(本記事参照)。

関連記事

まとめ

  • 改名後pushエラーは6パターン:upstream未設定/同名衝突/旧残存/保護/default/リモート先行改名
  • 最多は①upstream未設定——git push -u origin new-nameで解決
  • 正しい4ステップ:ローカル改名→新名push→旧名削除→prune
  • PRがあるブランチはGitHub Rename機能を優先(自動追従)
  • default branchは管理画面で切替が先、旧名削除が後
  • 予防:push.autoSetupRemote=truefetch.prune=true/エイリアス化
  • 共有ブランチ改名は必ずチーム通知+追従手順の共有

改名後のpushエラーはメッセージ内容とgit branch -vvの出力で原因が特定できます。6パターン早見表を参考に、「upstreamを張り直す」「旧名を消す」「default branchは管理画面先」の3つのポイントを押さえれば、ほぼ全ケースを安全に解決できます。PRが絡む場面ではGitHub Rename機能を活用し、CLI改名は個人ブランチに限定する運用が最もトラブルが少ないでしょう。