はい、承知いたしました。Gitのブランチ削除に関する初心者向けのガイド記事を、約5000語の詳細な説明を含めて記述します。
【初心者向け】Git ブランチ削除ガイド:コマンドと注意点
Gitを使った開発は、ブランチという強力な機能を活用することで、より効率的かつ安全に進めることができます。新しい機能の開発、バグ修正、試行錯誤など、様々な目的に応じてブランチを作成し、独立した作業空間として利用します。
しかし、開発が進むにつれてブランチの数は増えていきます。役割を終えたブランチ、間違って作成したブランチ、実験のために作ったものの不要になったブランチなどがリポジトリ内に溜まっていくと、全体の状況が把握しにくくなり、管理が煩雑になってしまいます。
本記事は、Gitを使い始めたばかりの初心者の方を対象に、増えすぎたブランチを安全かつ適切に削除する方法を、コマンドの使い方から注意点まで、詳しく丁寧に解説します。ブランチを整理整頓し、より快適なGitライフを送りましょう。
はじめに:なぜブランチを削除する必要があるのか?
Gitにおけるブランチは、開発の並行作業を可能にする非常に便利な機能です。たとえるなら、本を読むときに複数の「しおり」を挟んでおき、好きなときにその場所に戻って読み進めるようなものです。開発においては、main
(またはmaster
)ブランチという「完成版」のしおりとは別に、新しい機能開発用のfeature
ブランチ、バグ修正用のhotfix
ブランチなど、作業ごとのしおりを作成して、メインの流れを邪魔せずに作業を進めることができます。
このように便利なブランチですが、作業が完了し、その内容が他のブランチ(例えばmain
ブランチ)に取り込まれた後も、元のブランチはそのまま残っています。ブランチの数が少なければ問題ありませんが、プロジェクトが大きくなったり、開発期間が長くなったりすると、あっという間にブランチリストは長大になります。
増えすぎたブランチは、以下のような問題を引き起こす可能性があります。
- 可読性の低下: どのブランチが現在アクティブなのか、どのブランチが役割を終えているのかが一目で分かりにくくなります。
- 誤操作のリスク増加: 意図しないブランチで作業を開始したり、間違ったブランチにマージしたりするリスクが高まります。
- 管理の煩雑化: ブランチが多すぎると、Gitクライアントの表示が乱雑になったり、コマンド入力時に間違えやすくなったりします。
- (わずかながら)リポジトリサイズの増大: ブランチ自体は軽い情報ですが、大量のブランチが存在すると管理情報が増えます。
これらの問題を避けるために、役割を終えたブランチは適切に削除することが推奨されます。ブランチの削除は、開発プロセスにおける「整理整頓」の一部と言えるでしょう。
この記事では、ローカル環境にあるブランチと、リモートリポジトリにあるブランチの、それぞれの削除方法について、具体的なコマンドと、実行前に知っておくべき重要な注意点を中心に解説します。
Gitブランチ削除の基本概念
ブランチを削除する前に、いくつか基本的な考え方をおさえておきましょう。
-
ローカルブランチとリモートブランチ:
- ローカルブランチ: 自分のPC上にあるリポジトリ内のブランチです。普段
git branch
コマンドで確認できるのは、主にこのローカルブランチです。 - リモートブランチ: GitHubやGitLabなどのリモートリポジトリ上にあるブランチです。
git branch -r
コマンドで確認できます(正確には、リモートリポジトリのブランチをローカルが追跡している「リモート追跡ブランチ」が表示されます)。
ブランチを完全に削除するには、ローカルブランチとリモートブランチの両方を削除する必要があります。
- ローカルブランチ: 自分のPC上にあるリポジトリ内のブランチです。普段
-
安全な削除と強制削除:
Gitのブランチ削除コマンドには、安全性のレベルが異なる2つの主要なオプションがあります。- 安全な削除: そのブランチのコミットが、他の主要なブランチ(例えば
main
やマージ先として指定したブランチ)にすべてマージ済みであるかを確認し、マージ済みであれば削除を許可します。まだマージされていないコミットが残っている場合は、データ消失を防ぐために削除を拒否します。 - 強制削除: マージ済みであるかどうかにかかわらず、問答無用でブランチを削除します。これは未マージのコミットが存在する場合でも削除できるため、データ消失のリスクを伴います。
- 安全な削除: そのブランチのコミットが、他の主要なブランチ(例えば
これらの違いを理解することが、安全なブランチ運用において非常に重要です。通常は、安全な削除から試み、どうしても削除できない場合や、未マージの内容が不要であることが確実な場合にのみ、強制削除を使用します。
ローカルブランチの削除
まずは、自分のPC上にあるローカルブランチを削除する方法を見ていきましょう。
1. 安全な削除: git branch -d <branch-name>
git branch -d
コマンドは、ブランチを削除するための最も基本的で安全な方法です。
- コマンドの形式:
git branch -d <削除したいブランチ名>
-d
オプション:--delete
の短縮形です。このオプションを指定すると、Gitは削除対象のブランチのすべてのコミットが、現在のブランチまたはそのupstreamブランチ(リモートブランチと追跡関係にあるローカルブランチの場合)にマージされているかどうかを確認します。- 動作:
- 削除対象のブランチのコミットが、マージ先ブランチにすべて含まれている(マージ済みである)場合、ブランチは削除されます。
- 削除対象のブランチに、マージ先ブランチに含まれていないコミットがある(未マージである)場合、ブランチの削除は拒否されます。これは、まだ取り込まれていない大切な変更が失われるのを防ぐための安全機構です。
使用例:マージ済みブランチの削除
例えば、feature/add-user-profile
というブランチで作業し、その内容を main
ブランチにマージしたとします。このfeature/add-user-profile
ブランチはもう不要なので削除したい場合、現在のブランチがmain
(または別のブランチ)であることを確認してから以下のコマンドを実行します。
“`bash
まず、削除したいブランチとは別のブランチに移動します
例:mainブランチにいる場合
git checkout main
feature/add-user-profile ブランチを削除します
git branch -d feature/add-user-profile
“`
もし feature/add-user-profile
ブランチのすべてのコミットが main
ブランチにマージされていれば、以下のようなメッセージが表示されて削除が成功します。
Deleted branch feature/add-user-profile (was abc1234).
abc1234
の部分は、削除されたブランチのHEADコミットのハッシュです。
使用例:未マージブランチの削除(削除が拒否されるケース)
次に、feature/add-user-profile
ブランチにまだmain
ブランチにマージされていないコミットが残っている状態で、同じコマンドを実行してみます。
“`bash
mainブランチにいると仮定
git checkout main
feature/add-user-profile ブランチを削除しようとする
git branch -d feature/add-user-profile
“`
この場合、Gitは削除を拒否し、以下のようなエラーメッセージを表示します。
error: The branch 'feature/add-user-profile' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature/add-user-profile'.
このメッセージは、「feature/add-user-profile
ブランチはまだ完全にマージされていません。それでも削除したい場合は、git branch -D feature/add-user-profile
を実行してください。」という意味です。Gitは、まだ失われる可能性のあるコミットがあるため、安全のために削除を止めてくれたのです。
このエラーが出た場合は、以下のいずれかを検討してください。
- 本当にそのブランチの内容が必要なら、マージ先ブランチ(例:
main
)にマージします。 - そのブランチの内容がもう必要ない、あるいは間違って作成したブランチであるなど、未マージの変更が不要であることが確実な場合は、次に説明する強制削除コマンドを使用します。
2. 強制削除: git branch -D <branch-name>
git branch -D
コマンドは、マージ済みかどうかにかかわらず、指定したブランチを強制的に削除します。
- コマンドの形式:
git branch -D <削除したいブランチ名>
-D
オプション:--delete --force
の短縮形です。このオプションは、安全チェック(マージ済みの確認)をスキップし、強制的にブランチを削除します。- 動作: マージ済みかどうかにかかわらず、問答無用でブランチを削除します。
使用例:未マージブランチの強制削除
前述の例で、未マージのコミットが残っている feature/add-user-profile
ブランチを、やはり削除したいと判断した場合に使用します。例えば、「このブランチで試したことは失敗だったので、すべて無かったことにしたい」という場合などです。
“`bash
mainブランチにいると仮定
git checkout main
feature/add-user-profile ブランチを強制削除する
git branch -D feature/add-user-profile
“`
今度は、マージ済みかどうかにかかわらず、以下のようなメッセージが表示されて削除が成功します。
Deleted branch feature/add-user-profile (was abc1234).
注意点: git branch -D
は非常に強力なコマンドです。未マージのコミットがあるブランチをこのコマンドで削除すると、その未マージのコミットは失われる可能性があります。本当にそのブランチの内容が不要であることを十分に確認してから使用してください。特に、他の開発者と共有しているブランチや、まだ誰もレビューしていないブランチを強制削除するのは避けるべきです。
3. 現在のブランチを削除しようとした場合
Gitでは、現在作業中の(git checkout
している)ブランチを直接削除することはできません。もし現在のブランチを削除しようとすると、以下のようなエラーが発生します。
“`bash
feature/my-branch ブランチにいると仮定
git branch -d feature/my-branch
“`
エラーメッセージ:
error: Cannot delete branch 'feature/my-branch' checked out at '/path/to/your/repository'
解決策: 削除したいブランチから、別のブランチ(例えばmain
やdevelop
など、安全な場所)に移動してから削除コマンドを実行してください。
“`bash
現在のブランチ(feature/my-branch)から main ブランチに移動
git checkout main
feature/my-branch ブランチを削除
git branch -d feature/my-branch
“`
4. 複数のローカルブランチをまとめて削除
役割を終えたブランチがたくさん溜まっている場合、一つずつ削除するのは手間がかかります。特定の条件を満たすブランチをまとめて削除したい場合、シェルスクリプトやGitコマンドの組み合わせで実現できます。
よくあるシナリオは、「すでにマージ済みのローカルブランチをすべて削除したい」というものです。これはgit branch --merged
オプションと他のコマンドを組み合わせることで実現できます。
git branch --merged
: 現在のブランチにマージ済みのブランチをリストアップします。--no-merged
: 現在のブランチにまだマージされていないブランチをリストアップします。
これらのオプションを使って、削除したいブランチのリストを作成し、そのリストに対して削除コマンドを適用します。
使用例:マージ済みのローカルブランチをまとめて削除
以下のコマンドは、現在のブランチ(例: main
)にマージ済みのローカルブランチをすべて表示し、その中からmain
やdevelop
といった主要なブランチを除外し、残りのブランチを安全に削除する例です。
“`bash
現在のブランチが main であることを確認(または削除対象ブランチがマージされたブランチへ移動)
git checkout main
mainにマージ済みのローカルブランチをリストアップし、grepで除外、xargsで削除コマンドを実行
git branch –merged main | grep -v ‘^*’ | grep -v ‘ main$’ | xargs git branch -d
“`
このコマンドを分解して説明します。
git branch --merged main
:main
ブランチにマージ済みのローカルブランチをリストアップします。各行の先頭にブランチ名が表示されます。現在のブランチには*
が付きます。|
: パイプ。左側のコマンドの出力を右側のコマンドの入力として渡します。grep -v '^\*'
: リストの中から、行頭に*
がついている行を除外します。これは「現在のブランチ」を削除対象から外すためです。|
: 再びパイプ。grep -v ' main$'
: リストの中から、ブランチ名がmain
で終わる行を除外します。これはmain
ブランチ自体を削除対象から外すためです。もしdevelop
ブランチなども残したい場合は、grep -v ' main$' | grep -v ' develop$'
のように追加します。|
: 再びパイプ。xargs git branch -d
: 前のコマンドから渡された各行(ブランチ名)を引数として受け取り、それぞれに対してgit branch -d
コマンドを実行します。
重要な注意点:
- このコマンドを実行する前に、
git branch --merged main
の出力を見て、削除されて困るブランチが含まれていないか十分に確認してください。 - このコマンドは、現在のブランチにマージ済みのブランチを削除します。したがって、どのブランチからこのコマンドを実行するかが重要です。通常は、主要な開発ブランチ(
main
やdevelop
など)に移動してから実行します。 - このコマンドはローカルブランチのみを削除します。リモートブランチは削除されません。
より安全に行うには、まず削除対象のリストを確認するだけにとどめ、問題なければ削除を実行する、という二段階のステップを踏むと良いでしょう。
“`bash
削除候補のリストを確認
git branch –merged main | grep -v ‘^*’ | grep -v ‘ main$’
リストを確認して問題なければ、以下のコマンドで削除実行
git branch –merged main | grep -v ‘^*’ | grep -v ‘ main$’ | xargs git branch -d
“`
リモートブランチの削除
ローカルブランチを削除しただけでは、リモートリポジトリ上のブランチはそのまま残っています。共同開発している場合、他の開発者からはまだそのブランチが見えてしまいますし、リモートリポジトリの整理にもなりません。役割を終えたブランチは、リモートリポジトリからも削除することが推奨されます。
リモートブランチの削除は、git push
コマンドを使用します。
1. 基本コマンド: git push <remote-name> --delete <branch-name>
これは、リモートブランチを削除するための最も一般的で推奨される方法です。
- コマンドの形式:
git push <リモート名> --delete <削除したいブランチ名>
<リモート名>
: 通常はorigin
ですが、リポジトリによっては異なる場合があります。git remote -v
で確認できます。--delete
オプション: リモートリポジトリから指定したブランチを削除するように指示します。
使用例:リモートブランチの削除
ローカルで feature/add-user-profile
ブランチを開発し、リモートにプッシュし、その後マージされて不要になったとします。ローカルブランチは git branch -d feature/add-user-profile
で削除済みと仮定します。次にリモートの対応するブランチを削除します。
“`bash
リモート名が origin の場合
git push origin –delete feature/add-user-profile
“`
削除が成功すると、以下のようなメッセージが表示されます。
To https://github.com/yourname/yourrepo.git
- [deleted] feature/add-user-profile
これで、リモートリポジトリから feature/add-user-profile
ブランチが削除されました。
2. 代替コマンド (古い記法): git push <remote-name> :<branch-name>
これは git push --delete
と同じ効果を持つ古い記法です。現在でも使用可能ですが、--delete
の方が意図が明確で推奨されます。
- コマンドの形式:
git push <リモート名> :<削除したいブランチ名>
- コロン (
:
) の意味: この記法は、ローカルの何も参照しない場所(空の参照)を、リモートの指定したブランチにプッシュするという意味合いを持ちます。結果として、リモートのそのブランチは削除されます。
使用例:リモートブランチの削除(古い記法)
上記と同じ feature/add-user-profile
ブランチを削除する場合:
bash
git push origin :feature/add-user-profile
これも削除が成功すると、同様のメッセージが表示されます。
To https://github.com/yourname/yourrepo.git
- [deleted] feature/add-user-profile
どちらを使うべきか?: git push --delete
の方がコマンドの意図(削除したい)が明確に伝わるため、特別な理由がなければこちらを使うことをお勧めします。
リモートブランチ削除時の注意点
リモートブランチの削除は、ローカルだけの操作と異なり、他の開発者にも影響を与えます。以下の点に注意が必要です。
- 共同開発者への影響: 削除するブランチで他の開発者が作業している場合や、そのブランチを参照している場合、彼らの作業に影響が出る可能性があります。削除する前に、チーム内でコミュニケーションを取り、合意を得ることが重要です。プルリクエスト(またはマージリクエスト)がクローズ/マージされたタイミングで、関連ブランチを削除するなどのルールを決めておくと良いでしょう。
- 権限: リモートリポジトリによっては、ブランチの削除に特定の権限が必要な場合があります。権限がない場合は、リポジトリの管理者にお願いする必要があります。
- 保護されたブランチ:
main
,master
,develop
などの主要なブランチは、誤って削除されないように「保護されたブランチ」として設定されていることが多いです。これらのブランチは通常、権限があってもGUIや特定のコマンドでは削除できないようになっています。Gitの運用上、これらのブランチを削除することはまずありません。 - CI/CDパイプライン: 特定のブランチがプッシュされるとCI/CDパイプラインがトリガーされるように設定されている場合があります。削除によってパイプラインの設定に影響がないか確認しておくとより安全です。
ローカルに残ったリモート追跡ブランチの整理
リモートリポジトリからブランチを削除しても、ローカルリポジトリにはそのリモートブランチを追跡していた「リモート追跡ブランチ」の情報が残ることがあります。これは remotes/origin/feature/add-user-profile
のような形式で見えるものです。
git branch -r
コマンドでリモート追跡ブランチのリストを確認できます。
bash
git branch -r
origin/HEAD -> origin/main
origin/main
origin/develop
origin/feature/add-user-profile # <- リモートで削除済みなのに残っている場合がある
リモートで削除されたブランチに対応するリモート追跡ブランチをローカルから削除するには、git remote prune
コマンドを使用します。
- コマンドの形式:
git remote prune <リモート名>
- 動作: リモートリポジトリに存在しないブランチに対応するリモート追跡ブランチを、ローカルから削除します。
使用例:リモート追跡ブランチの整理
“`bash
リモート名が origin の場合
git remote prune origin
“`
実行すると、削除されたリモート追跡ブランチのリストが表示されます。
Pruning origin
URL: https://github.com/yourname/yourrepo.git
* [pruned] origin/feature/add-user-profile
または、git fetch
実行時に自動的に prune
を行うように設定することも可能です。git fetch --prune <リモート名>
を実行するか、.git/config
ファイルで [remote "origin"]
セクションに prune = true
を設定しておくと便利です。
“`bash
fetch と同時に prune を行う
git fetch –prune origin
“`
これで、ローカルブランチ、リモートブランチ、そしてそれらを追跡していたリモート追跡ブランチの、すべてが整理されました。
ブランチ削除の際の重要な注意点と確認事項
ブランチ削除は、特に共同開発においては慎重に行うべき操作です。削除コマンドを実行する前に、以下の点を必ず確認しましょう。
1. そのブランチは本当に不要か?(マージは完了しているか?)
これが最も重要な確認事項です。削除しようとしているブランチの変更内容が、完全に他のブランチ(通常はmain
やdevelop
など)に取り込まれているかを確認してください。
マージ済みかどうかの確認方法:
git branch --merged
: 現在のブランチにマージ済みのブランチをリストアップします。git branch --no-merged
: 現在のブランチにまだマージされていないブランチをリストアップします。
これらのコマンドを使って、削除したいブランチがどのリストに含まれているかを確認します。
例: 現在main
ブランチにいるとして、feature/my-feature
ブランチがマージ済みか確認したい場合。
bash
git checkout main
git branch --merged
もし出力リストに feature/my-feature
が含まれていれば、main
にマージ済みです。安全に git branch -d feature/my-feature
で削除できます。
bash
git branch --no-merged
もし出力リストに feature/my-feature
が含まれていれば、main
にはまだマージされていません。この場合、git branch -d
では削除できません。強制削除 (git branch -D
) は可能ですが、データ消失のリスクがあります。
未マージのコミット内容を確認する:
もし git branch --no-merged
でリストアップされたブランチを削除しようとしているなら、本当にその未マージの変更が不要か、改めて確認すべきです。以下のコマンドで、現在のブランチ(例: main
)にはなく、削除したいブランチ(例: feature/my-feature
)にあるコミットを確認できます。
bash
git log main..feature/my-feature
このコマンドは、feature/my-feature
ブランチには存在するが、main
ブランチには存在しないコミットを表示します。これらのコミットが、強制削除 (git branch -D
) によって失われる可能性があるコミットです。これらのコミットを確認し、本当に不要であることを確信してから強制削除を行いましょう。
2. 未プッシュのコミットはないか?
ローカルブランチに、まだリモートにプッシュしていない(リモート追跡ブランチに反映されていない)コミットがないか確認します。特に、git branch -D
で強制削除する場合、未プッシュのコミットは失われる可能性が高くなります。
“`bash
削除したいローカルブランチに移動
git checkout feature/my-feature
リモート追跡ブランチ(例: origin/feature/my-feature)との差分を確認
git log origin/feature/my-feature..HEAD
“`
このコマンドは、ローカルの feature/my-feature
には存在するが、リモートの origin/feature/my-feature
には存在しないコミットを表示します。もし何も表示されなければ、未プッシュのコミットはありません。コミットが表示された場合は、その内容をよく確認し、必要であればプッシュするか、内容をバックアップするなどの対応を検討してください。
3. 共同開発におけるコミュニケーション
チームで開発している場合、ブランチの削除は必ず他のメンバーと連携して行いましょう。
- プルリクエスト/マージリクエストの完了: 通常、GitHubやGitLabなどで作成したプルリクエストやマージリクエストが承認・マージされた後、自動的にブランチを削除するオプションが提供されています。これを利用するのが最もスムーズです。手動で削除する場合も、必ずマージが完了し、かつ他の開発者がそのブランチでの作業を終えていることを確認します。
- 削除ルールの取り決め: 「マージされたフィーチャーブランチは1週間後に削除する」「一定期間アクティビティのないブランチは削除を検討する」など、チーム内でブランチのライフサイクルと削除ルールを決めておくと、混乱を防ぐことができます。
- 重要なブランチは保護設定:
main
やdevelop
など、削除されると困るブランチは、リモートリポジトリ側で保護設定を有効にしておきましょう。
4. 万が一、誤って削除してしまった場合の復旧可能性 (git reflog
)
「ああ!間違えて必要なブランチを強制削除してしまった!」
このような事態に陥っても、慌てないでください。Gitには reflog
(Reference Log) という非常に便利な機能があり、多くの場合、削除してしまったブランチのコミットを復旧させることが可能です。
reflog
は、リポジトリのHEAD(現在作業中のコミット)が移動した履歴を記録しています。ブランチを切り替えたり、プルしたり、コミットをしたり、リベースしたり、そしてブランチを削除したりするたびに、HEADの新しい位置がreflogに記録されます。削除されたブランチの先端コミットも、HEADがそこを指していた時期があれば、reflogに残っている可能性があります。
git reflog
コマンドの使い方:
ターミナルで git reflog
と実行すると、HEADの移動履歴が新しい順に表示されます。
bash
git reflog
出力例:
a1b2c3d HEAD@{0}: checkout: moving from feature/old-branch to main
e4f5g6h HEAD@{1}: merge feature/my-feature: Merge made by the 'recursive' strategy.
i7j8k9l HEAD@{2}: checkout: moving from feature/my-feature to main
m1n2o3p HEAD@{3}: commit: Add user profile page
q4r5s6t HEAD@{4}: checkout: moving from main to feature/my-feature
u7v8w9x HEAD@{5}: pull origin main: Fast-forward
... (さらに古い履歴)
各行は「コミットハッシュ HEAD@{操作順序}: 操作内容: 操作の詳細」という形式になっています。
削除したブランチのコミットを探す:
削除してしまったブランチ(例: feature/lost-branch
)の復旧を試みるには、reflog
の履歴を遡って、そのブランチで作業していた頃のコミットを探します。操作内容やコミットメッセージを手がかりに、削除されたブランチの先端だったと思われるコミットのハッシュを見つけます。
例えば、上記の例で m1n2o3p
が削除された feature/lost-branch
で行った最後のコミットだったとします(操作内容が commit: Add user profile page
であることから推測)。
ブランチを復旧させる:
削除されたブランチの先端コミット(例: m1n2o3p
)のハッシュが分かれば、そのコミットを指す新しいブランチを作成することで、簡単に復旧できます。
方法1: git checkout
で新しいブランチを作成し、そこに移動する
bash
git checkout -b feature/recovered-branch m1n2o3p
これは、「m1n2o3p
コミットから分岐する feature/recovered-branch
という新しいブランチを作成し、そこにチェックアウト(移動)する」という意味です。
方法2: git branch
で新しいブランチを作成する(現在のブランチは移動しない)
bash
git branch feature/recovered-branch m1n2o3p
これは、「m1n2o3p
コミットを指す feature/recovered-branch
という新しいブランチを作成する」という意味です。現在のブランチは変わりません。
どちらの方法でも、削除してしまったブランチの履歴(m1n2o3p
コミットとその親コミット)が、新しいブランチ feature/recovered-branch
として復旧されます。
reflog
の限界:
reflog
は非常に強力ですが、万能ではありません。
reflog
はローカルリポジトリ固有の履歴です。リモートリポジトリにはありません。ローカルリポジトリ自体を失ったり破損させたりすると、reflogの情報も失われます。- reflogの履歴は永久に保存されるわけではありません。デフォルトでは90日間(または設定による)で古いエントリは期限切れとなり、Gitのガーベージコレクションによって削除される可能性があります。
したがって、reflog
はあくまで「最後の砦」であり、削除は慎重に行うことが最も重要です。特に、git branch -D
を使用する際は、内容が本当に不要であることを十分に確認してから実行してください。
実践的なシナリオと例
これまでに解説したコマンドと注意点を踏まえ、いくつかの具体的なシナリオでブランチ削除の流れを見てみましょう。
シナリオ1: フィーチャーブランチの開発完了と削除
main
ブランチからfeature/new-feature
ブランチを作成し、作業を進める。
bash
git checkout main
git pull origin main # 最新の状態を取得
git checkout -b feature/new-feature
# ... 開発作業 ...
git commit -m "feat: add new feature"
git push origin feature/new-feature # リモートにもプッシュ- 開発が完了し、
main
ブランチへのマージ(またはプルリクエストの作成・マージ)が完了した。 - ローカルの
feature/new-feature
ブランチを削除する。マージ済みなので-d
で安全に削除できるはず。
bash
git checkout main # mainブランチなど、削除対象以外のブランチに移動
git branch -d feature/new-feature
もし「not fully merged」と出たら、本当にマージされているか確認し、されていなければマージするか、未マージ部分が不要なら-D
を検討する。 - リモートの
feature/new-feature
ブランチを削除する。
bash
git push origin --delete feature/new-feature - ローカルに残ったリモート追跡ブランチを整理する。
bash
git remote prune origin
シナリオ2: 間違って作成したローカルブランチの削除
- タイプミスや勘違いで
featrue/my-feature
のように間違ったブランチ名でブランチを作成してしまった。
bash
git checkout -b featrue/my-feature - すぐに間違いに気づいた。このブランチにはまだ何もコミットしていない(または、していても不要な変更である)。
- 間違ったブランチを削除する。このブランチには必要なコミットは含まれていないので、未マージでも構わない。
-D
で強制削除する。
bash
git checkout main # 別のブランチに移動
git branch -D featrue/my-feature
もし、間違ったブランチに移動する前に削除しようとした場合は、「Cannot delete branch … checked out at …」というエラーが出るので、別のブランチに移動してから再度実行する。
シナリオ3: リモートでマージされたブランチのローカル追跡ブランチが残っている
- 他の開発者がフィーチャーブランチを作成・プッシュし、プルリクエスト経由でマージ後、リモートブランチも削除した。
- 自分のローカルリポジトリを
git fetch
で最新の状態にしても、git branch -r
を見ると削除されたはずのリモート追跡ブランチ(例:origin/another/feature
)が残っている。
bash
git fetch origin
git branch -r
# 表示されたリストに origin/another/feature が残っている - ローカルに残ったリモート追跡ブランチを整理する。
bash
git remote prune origin
# または git fetch --prune origin を実行
これで、git branch -r
のリストからorigin/another/feature
が消えるはずです。
まとめ:安全なブランチ運用のために
Gitのブランチ削除は、リポジトリをきれいに保ち、開発効率を上げるために必要な作業です。しかし、特にgit branch -D
やリモートブランチの削除は、使い方を誤ると重要な変更を失ったり、共同開発者に迷惑をかけたりする可能性があります。
この記事で解説したポイントを改めてまとめます。
-
ローカルブランチの削除:
git branch -d <branch-name>
: 安全な削除。マージ済みであれば削除、未マージなら拒否。まずはこのコマンドを試しましょう。git branch -D <branch-name>
: 強制削除。マージ済みかどうかにかかわらず削除。未マージのコミットがある場合に使う際は、データ消失のリスクがあることを十分に理解し、本当に不要か確認してから使いましょう。- 現在チェックアウトしているブランチは削除できません。別のブランチに移動してから削除してください。
git branch --merged
やgit branch --no-merged
を活用して、まとめて削除することも可能です。
-
リモートブランチの削除:
git push <remote-name> --delete <branch-name>
: リモートブランチを削除するための推奨されるコマンドです。- リモートブランチの削除は、共同開発者に影響します。必ずチーム内でコミュニケーションを取り、合意を得てから実行しましょう。
- 主要なブランチ(
main
など)は通常保護されており、削除できません。 - リモートブランチを削除した後、ローカルに残ったリモート追跡ブランチは
git remote prune <remote-name>
で整理しましょう。
-
削除前の重要な確認事項:
- そのブランチは本当に不要か?特に、他のブランチにマージ済みであるか? (
git branch --merged
/--no-merged
で確認) - 削除対象のローカルブランチに、まだリモートにプッシュしていない重要なコミットはないか?
- 共同開発者はそのブランチで作業していないか?削除しても問題ないかチームに確認したか?
- そのブランチは本当に不要か?特に、他のブランチにマージ済みであるか? (
-
誤って削除してしまったら:
git reflog
コマンドでHEADの移動履歴を確認し、削除されたブランチの先端コミットを探します。- 見つけたコミットハッシュを使って
git branch <new-branch-name> <commit-hash>
またはgit checkout -b <new-branch-name> <commit-hash>
で新しいブランチとして復旧できる可能性があります。ただし、reflogにも期間制限など限界があります。
ブランチの削除は、単なるコマンド操作ではなく、開発プロセスにおける重要な整理整頓のステップです。これらのコマンドと注意点を理解し、実践することで、より安全かつ効率的にGitを使いこなせるようになるでしょう。定期的なブランチの整理を習慣にして、快適な開発環境を保ってください。
もし、この記事を読んで分からない点があれば、遠慮なくGitや開発チームに詳しい同僚に質問したり、公式ドキュメントや他の解説記事を参考にしたりしてください。一歩ずつ確実に理解を深めていきましょう。