【Git】git branch rename でブランチ面を変更する方法を初心者向けにわかりやすく解説
はじめに
Gitを使って開発をする際に、間違えて作成したブランチ名をそのまま放置して困った経験はありませんか。
もしくは、ブランチの役割が変わったために、すでにあるブランチ名を変更したいというケースがあるかもしれません。
このようなときに使われるのが、git branch rename の操作です。
ブランチ名の変更手順を理解すると、誤解を招かない分かりやすい命名でプロジェクトを進められます。
ここでは具体的なコマンド例と併せて、実務シーンでよくある「リモートブランチをどう取り扱うか」という部分についても整理します。
この記事を読むとわかること
- ブランチ名をローカルで変更する方法
- リモートブランチの名前を変更する場合の手順
- 実務での活用シーンと注意点
- チーム開発で混乱を避けるためのコツ
Gitのブランチをリネームする必要性
Gitでのブランチ運用は便利ですが、ブランチ名を間違って設定するとプロジェクトに混乱が生じる場合があります。
たとえば、別のチームメンバーがブランチの意図を勘違いしてしまったり、自分自身も作業の目的を忘れてしまう可能性があります。
ここでは、なぜブランチをリネームすることが重要なのか、その必要性を整理します。
ブランチ名は、作業内容や目的を端的に表す看板のような役割を持ちます。
不要に長い、あるいは内容を誤解しやすい名前のまま放置すると、チーム全体に影響が及ぶかもしれません。
たとえば「feature/refactor」なのに実際はバグ修正しかしていないようなケースでは、見る人が意図を把握しづらくなります。
実務では、ある程度規約に沿ったブランチ命名をしていることが多いでしょう。
しかし、うっかり命名を間違えてコミットを積んでしまったり、後から別の担当者に改修内容を引き継ぐ必要が生じる場面もあります。
そこで、間違ったままのブランチ名を使い続けるのではなく、適切な名前に変更する手段を知っておくと便利です。
ローカルブランチをリネームする基本的な方法
ローカルで作成してあるブランチ名を変えたい場合には、git branch -m というコマンドをよく使います。
ここでは、いくつかのコード例を挙げて説明します。
ローカルブランチ名を変更する手順
もっとも簡単な方法は、次のようにブランチの名前を変更するやり方です。
# すでに対象ブランチをチェックアウトしている場合 git branch -m new-branch-name
この書き方は、今アクティブになっているブランチ名をそのまま new-branch-name
に置き換える方法です。
ただ、もし現在のブランチが違う場合は、ブランチの存在を指定してリネームする方法もあります。
# 他のブランチにいる状態で git branch -m old-branch-name new-branch-name
こうすれば、自分が今チェックアウトしていないブランチに対してもリネームできます。
ちなみに -m
は「移動 (move)」という意味で捉えるとわかりやすいかもしれません。
実務での活用シーン
機能追加用に「feature/add-login」などと命名したつもりが「featue/add-login」になっていた場合など、つづりを誤っていても後で修正できます。
このときにブランチ名をきちんと直しておくことで、チームメンバーにも意図が正確に伝わり、無用のトラブルを避けられます。
リモートブランチをリネームする場合の流れ
ローカルでのブランチ名変更ができたら、そのブランチをリモートにも反映したい場面が多いでしょう。
たとえば、GitHubやGitLab、Bitbucketなどのリモートリポジトリと連携して開発している場合は、別の手順が必要になります。
一度リモートブランチを削除して新しい名前でプッシュする
Gitでは、ブランチ名を直接変更するコマンドはローカル向けに提供されていますが、リモートブランチを置き換える仕組みは少し面倒です。
基本的には、不要になった古い名前のブランチをリモートから削除し、新しい名前のブランチをリモートに作成する流れになります。
# ローカルブランチ名を変更した上で git push origin :old-branch-name new-branch-name
上記のコマンドは「old-branch-name ブランチをリモートから削除し、新しく new-branch-name をプッシュする」という意味合いになります。
この操作を実行したら、リポジトリのリモート上で旧ブランチが削除され、同じコミットを指すブランチとして new-branch-name が作られます。
リモートでのリネームを完了した後の確認
実務では、共同作業者もリポジトリにアクセスしている可能性があるため、旧ブランチ名を見つけたメンバーが戸惑わないよう、変更したことを周知する必要があります。
また、CIツールやデプロイ設定でブランチ名を固定している場合などは、設定を更新しなければならないケースもあるでしょう。
チーム開発においては、以前のブランチ名を参照しているプルリクエストや課題管理システムのリンクが残っていないかをチェックします。
そのまま放置すると、リンク切れや「該当ブランチなし」というような表示が出て、トラブルの原因になりかねません。
リモート追跡ブランチの扱い
Gitでは、ローカルブランチを作成するときにリモートブランチと同期をとる「リモート追跡ブランチ」が生成されることがあります。
たとえば git fetch
や git pull
をするときに、どのリモートブランチと同期するのかをGitが認識している仕組みです。
リモートブランチをリネームしたらローカルの追跡設定を変更する
ローカルでブランチ名を変更し、かつリモートブランチも変更した場合には、追跡先を手動で切り替える必要があります。
具体的には、以下のような流れを意識すると良いでしょう。
# 1. ローカルでブランチ名を変更 git branch -m old-branch-name new-branch-name # 2. 新しいブランチ名をリモートにプッシュ git push origin :old-branch-name new-branch-name # 3. ローカルブランチ new-branch-name をリモート new-branch-name と追跡させる git push --set-upstream origin new-branch-name
ここで --set-upstream
オプションを使うのは、ローカルブランチをリモートブランチと関連付ける手段です。
こうすると、次回以降は単純な git pull
や git push
で同期が行いやすくなります。
変更時にエラーが出る場合の対処
ブランチをリネームしようとすると、既に存在する名前のブランチがある場合や、権限の問題で push に失敗するといったエラーが起こる可能性があります。
ここではよくあるケースを整理しておきます。
すでに使われているブランチ名がある
Gitは重複するブランチ名があるとコンフリクトを防ぐためにエラーを出します。
名前が重複していないか、改めて確認しましょう。
チーム開発で同じような命名規則を使っていると、アンダースコアやハイフンの有無など、ほんの少しの違いで混同することも考えられます。
リモートに push が拒否される場合
権限や保護されたブランチの設定があると、リモート側で push が禁止されていることがあります。
たとえば「main」「master」「develop」など、チームルールで強力に保護されているブランチには変更を加えられないよう制限している場合があります。
設定を見直したり、必要に応じて管理者に問い合わせてみましょう。
ブランチ保護ルールによっては、リモートからブランチ削除ができない可能性があります。 その場合は、管理者やチームのルールに沿って手順を変える必要があるかもしれません。
チームで混乱を避けるためのコツ
Gitのブランチ名を変更すること自体は簡単ですが、変更後にチームが混乱しないようにする工夫が必要になります。
名前が変わることで、レビュー待ちのプルリクエストや連携サービスのリンク先も動かなくなるかもしれません。
ここでは、変更時によく行われる対策をいくつか挙げます。
コミュニケーションツールで周知する
実務であれば、チャットツールやプロジェクト管理システム上で「○○ブランチは△△に名称変更しました」と共有するだけで、トラブルをかなり減らせます。
更新を知らずに pull や push しようとしてエラーを起こすことが防げるでしょう。
プルリクエストの更新
GitHubやGitLabでプルリクエストを出している途中に名前を変えた場合、ブランチを指し示す情報が旧のままになることがあります。
Pull Request のページを手動で更新するか、新しいブランチ名で再度プルリクエストを作るなど、どちらが適切か検討します。
議論やレビューの履歴を引き継ぐためにも、メンバー同士で相談しながら進めると安心です。
CIやデプロイ設定の修正
CIツールや自動デプロイ設定でブランチ名が固定されている場合には、リネーム後に設定を直さない限りビルドが動作しないケースがあります。
「新しいブランチ名で再度登録する」などの手順を踏む必要があるでしょう。
ブランチ名変更後は、CIやデプロイの動作確認を行いましょう。 問題があれば設定ファイル内のブランチ指定を見直すことをおすすめします。
ブランチ名を変更するときの具体的な例
ブランチをまったく作ったことがない初心者の皆さんでも理解しやすいように、簡単な手順例をまとめます。
たとえば以下のような状況を想定します。
- 誤って
feture/login-screen
というブランチを作成してしまった - 正しいブランチ名は
feature/login-screen
この場合、ローカルの修正とリモートの更新は以下のように行います。
# 1. 間違ったブランチ名にチェックアウト git checkout feture/login-screen # 2. 正しいブランチ名に変更 git branch -m feature/login-screen # 3. リモートから古いブランチを削除し、新しいブランチを作成 git push origin :feture/login-screen feature/login-screen # 4. 新しいブランチをリモート追跡ブランチに設定 git push --set-upstream origin feature/login-screen
こうすれば feture/login-screen
のリモートブランチは削除され、正しい名前の feature/login-screen
がリモート上に作成されます。
過去のコミット履歴は変わらない
ブランチの名前を変えるのは、あくまで参照名の移動にすぎません。
例えば、コミットの履歴や内容は変化しませんので、履歴が壊れるわけではありません。
そのため、比較的安心してブランチ名変更を行えると考えて構いません。
ただ、ブランチ保護や制限の設定があるときには管理者の協力が必要になったり、いったん保護ルールを外さないと変更できない場合があります。
この点はチームルールやプロジェクトの方針に合わせて対処するとよいでしょう。
まとめ
git branch rename は誤ったブランチ名や目的が変わったブランチ名を修正するときに役立つ操作です。
ローカルでは git branch -m old-name new-name
を使い、リモートブランチを更新するときには一度古いブランチを削除してから新しい名前で push する流れになります。
また、ブランチ名を変えると、プルリクエストやCI、デプロイ設定などに影響が及ぶケースがあります。
チームが混乱しないように周知したり、関連設定を見直すことが大切です。
ブランチ名を適切に管理すれば、プロジェクト内のコミュニケーションをスムーズにし、作業内容を把握しやすくなります。
ぜひ参考にしてみてください。