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未設定。改名したブランチはリモートとの紐付けが切れているので、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設定が必要です。
# ローカル改名(既にやっていればスキップ) 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が拒否されます。
# 最新情報取得 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ステップ改名フロー
- ローカル改名:
git branch -m old-name new-name - 新名でpush+upstream設定:
git push -u origin new-name - 旧リモート削除:
git push origin --delete old-name - 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も削除も通らないので要注意。
# 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 Actions:
on: 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 --prune+git 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
シナリオ② リモートに同名ブランチがあって衝突
git fetch --prune git rebase origin/new-name # conflict解消→continue git push -u origin new-name
シナリオ③ 自分のブランチがgoneと表示される
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で追跡情報の自動整理
# 自動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等に貼るのがマナーです。
よくある質問
git push -u origin 現在のブランチ名で1発解決。Git 2.37+ならpush.autoSetupRemote=true設定で初回push時の-u忘れが自動解消します。git fetch --pruneで整理、必要に応じてgit branch -u origin/新名で追跡先を付け替えましょう。git push origin --delete masterを実行してください。--force-with-leaseが必要になることがあります。git fetch --prune→git branch -m old new→git branch -u origin/newの3ステップ。改名担当者がこの手順をチーム共有すれば混乱なし。rename-branch old newコマンドを自作しておくと「ローカル改名→push→旧削除→prune」を1行で実行できます(本記事参照)。関連記事
- 【Git】ブランチ名を変更する方法 — 改名手順の全体像(4ステップ)
- 【Git】pushしようとしたら”non-fast-forward”で拒否されたときの解決方法 — 同名競合時の対処
- 【Git】originとupstreamの違いと使い分け完全ガイド — upstream概念の深掘り
- 【Git】ブランチを削除する方法 — 旧名削除の詳細
- 【Git】リモートブランチを確認する方法 — 改名後の状態確認
- 【Git】「failed to push some refs to」エラーの原因と対処法 — push拒否の総合窓口
- 【Git】pushを取り消す方法 — 誤ったpushの取消
- 【Git】よく使うgitコマンドまとめ — 日常コマンドの早見表
まとめ
- 改名後pushエラーは6パターン:upstream未設定/同名衝突/旧残存/保護/default/リモート先行改名
- 最多は①upstream未設定——
git push -u origin new-nameで解決 - 正しい4ステップ:ローカル改名→新名push→旧名削除→prune
- PRがあるブランチはGitHub Rename機能を優先(自動追従)
- default branchは管理画面で切替が先、旧名削除が後
- 予防:
push.autoSetupRemote=true/fetch.prune=true/エイリアス化 - 共有ブランチ改名は必ずチーム通知+追従手順の共有
改名後のpushエラーはメッセージ内容とgit branch -vvの出力で原因が特定できます。6パターン早見表を参考に、「upstreamを張り直す」「旧名を消す」「default branchは管理画面先」の3つのポイントを押さえれば、ほぼ全ケースを安全に解決できます。PRが絡む場面ではGitHub Rename機能を活用し、CLI改名は個人ブランチに限定する運用が最もトラブルが少ないでしょう。

