Gitのブランチ名はローカルで変更できます。ただし、手元の名前を変えても、共有リポジトリの参照や他の担当者の設定が一緒に変わるとは限りません。
ここでは改名する範囲を確認し、作業を引き継げる形で名前を変更する考え方を整理します。コマンドは説明用の未実行例です。
最初に改名する範囲を決める
自分だけが使う未共有ブランチと、プルリクエストや自動処理が参照する共有ブランチでは、確認する相手が異なります。
| 状態 | 先に確認する対象 |
|---|---|
| 手元だけにある | 現在の名前・変更内容・新しい名前 |
| 共有済み | 共同作業者・追跡先・公開済みの参照 |
| 既定ブランチや自動処理が使う | 保護規則・実行条件・外部リンク・管理者 |
ここでの表は作業範囲を決めるための整理です。単なる誤字修正でも、外部から参照されていれば共有側の変更として扱います。
ローカルでは強制しない改名から始める
git branch -mはブランチを、その設定やreflogとともに改名します。次はtopic/old-nameをtopic/new-nameへ変更する例です。Git公式branch仕様
git status
git branch -m topic/old-name topic/new-name
git branch -vv既に同じ新名がある場合は、そのブランチの役割を調べます。衝突を解消する目的が不明なまま強制改名しないでください。変更後は、名前だけでなく指しているコミットや追跡先も確認します。
共有側の名前は別に確認する
ローカルの改名と、リモート参照の更新は別の操作です。git pushの仕様にある追跡先設定や参照削除を、必要な範囲に限定して使います。
共有済みなら、まず利用しているホスティングサービスの改名機能と影響範囲を確認します。GitHubのブランチ改名の案内も、ローカルの更新や、リダイレクトされない参照の注意点を分けて説明しています。
「新名をpushして旧名を削除する」手順を、すべての共有ブランチに一律適用しないことが大切です。プルリクエストや自動処理への影響を調べ、旧名を消してよい時点を決めます。
改名後に参照を照合する
仮に、手元はtopic/new-nameへ変わった一方で、CIの条件が旧名のままだったとします。pushに成功しても想定の処理が実行されないため、改名そのものと自動処理の結果を別に確認する必要があります。
共同作業者には、新旧名、変更した共有先、手元で必要な更新を伝えます。確認記録にはコミットも添えると、名前が違うだけか内容も違うかを比較できます。
変更の目的と完了条件を残す
改名の完了条件は「一覧に新名が出る」だけでなく、必要な参照が新名を使い、作業が継続できることです。自動処理との関係はCI/CDパイプラインの設計も併せて整理できます。
まずは、旧名を参照している場所を列挙し、自分だけで変更できる範囲と調整が必要な範囲を分けましょう。