チームでは機能追加のブランチ名を feature/xxx にするルールですが、うっかり feat/user-login という名前でブランチを切ってコミット・プッシュし、そのままプルリクエストまで作成してしまいました。まだマージはされておらず、レビューも始まっていません。ブランチ名をルールに合わせたい場合、最も適切な対処はどれでしょうか。

解説

プルリクエスト（以下 PR）は「どのブランチから どのブランチへ」というブランチ参照にひも付いており、ソースブランチ名そのものを後から差し替える仕組みは GitHub には用意されていません。そのため、まだレビューが始まっていない段階であれば、PR をクローズして正しい名前のブランチを作り直し、新しく PR を開き直すのが最もシンプルで事故が少ない方法です。選択肢1は、ローカルで git branch -m してもリモートには別名の新しいブランチがプッシュされるだけで、元の feat/user-login ブランチと既存 PR はそのまま残ります。選択肢2は PR のタイトルや説明文は編集できますが、ソースブランチ名の項目は編集できません。選択肢4の .git/config はローカルの追跡設定に過ぎず、リモートブランチ名には何の影響もありません。プルリクエストがブランチ参照に縛られる理由PR は内部的には「base ブランチと head ブランチの差分を表示し、マージ時に head を base に取り込む」という操作の予約票のようなものです。head に指定されたブランチ名（正確には ref）はデータベース上のキーとして扱われているため、GitHub 側で名前だけを付け替える API が原則提供されていません。リポジトリ単位のブランチリネーム機能はありますが、これはデフォルトブランチ（main など）の改名を想定したもので、作業用ブランチの PR 途中リネームには向きません。コミットを安全に載せ替える手順実務ではこう進めると迷いません。git checkout feat/user-login git checkout -b feature/user-login git push origin feature/user-login # GitHub 上で元の PR をクローズし、新ブランチで PR を作り直す git push origin --delete feat/user-login新ブランチは既存ブランチから派生させるので、コミット履歴はそのまま引き継がれます。チェリーピックや rebase は不要で、ブランチは単なる「コミットへのポインタ」だというGitの本質を思い出すとシンプルに理解できます。レビューが進んでいた場合はどう考えるか既についたレビューコメントを失いたくないなら、命名規則違反を一度許容してマージ後に諦めるのも現実的な判断ですどうしても作り直すなら、新 PR の説明欄に旧 PR へのリンクを貼ってコンテキストを引き継ぐとレビュアーに親切ですそもそもこの種の事故を防ぐには、pre-push フックや CI でブランチ名の正規表現チェックを入れておくのが王道です「PR のブランチ名を変えたい」と思ったときは、PR はブランチに貼られた付箋であってブランチそのものではない、と捉え直すと、作り直し一択という結論に自然にたどり着けます。