Gitは、コーディングプロジェクトのバージョン管理を導入する優れたサービスです。実際、その利便性は非常に高く、ほとんど必須のツールとなっています。
メインリポジトリの複製ブランチを作成し、コードに手を加え、変更を残りのブランチにマージするという手順を踏みます。このため、リポジトリには多くの古いブランチが存在することになります。これらのファイルサイズは小さいことが多いのですが、それでもローカルブランチでgit deleteを実行し、整理整頓をしたいものです。
これの実行にはあまり手間がかかりません。しかし、変更をマージするかどうかによって最適な方法を検討する必要がありますし、削除の過程でエラーが発生した場合の対処も必要です。また、削除したブランチの復元が必要になる場合もあります。そのような状況では、それぞれ異なるスキルやコマンドが必要になります。
このページでは、ローカルブランチの削除コマンドの使い方をご紹介します。まず最初に、Gitでローカルブランチを削除するケースやその理由性について説明します。
Gitブランチとは
Gitリポジトリは、ブランチの集合体です。ブランチとは、その中のコアコードの複製です。実際、ブランチがなければGitリポジトリは成り立ちません。
多くの場合、プライマリリポジトリ（正式名称は「main」と「trunk」）があります。このリポジトリには、本番用のコードが含まれています。これを直接編集する代わりに、メインリポジトリの複製ブランチを作成し、そのブランチに必要な変更を加えます。そして、その内容をコアのコードに戻す処理として、チェックとマージを行います。
ブランチを使うことで、チームの全員が同じプロジェクトで、互いに独立した形で共同作業を行うことが可能です。また、作業中のコードに変更を加えたり、他の変更に干渉したりする危険を回避できます。
しかし、ローカルブランチでgit deleteを実行する必要も生じます。定期的な操作となることが予想され、そうしなければならない確固たる理由がいくつもあります。
なぜGitのブランチを削除するのか
本番用のコードは「main」ブランチにあります。このブランチは、永続性を持つ唯一のブランチです。
これに対して、作成したブランチのほとんどは、一時的に保存されることになります。作業が完了したら、変更をコミットし、メインブランチとのマージを検討します。
つまり、プロジェクトやチームによっては、一度にたくさんのブランチが混在する状況は珍しくありません。しかし、マージを確定させても、その他のブランチは消えません。
Gitローカルブランチの削除が必要になる理由は以下のように複数あります。
- 整理整頓：家では、料理を終えたら調理器具を洗って片付けます。Git リポジトリで作業するときも同じです。作業を終えたら、変更をマージし、不要になったブランチを削除します。作業が終わったら、変更をマージし、不要になったブランチを削除。こうすることで、プロジェクトやリポジトリのナビゲーションも簡単になります。
- リポジトリのファイルサイズ：Gitリポジトリは、プロジェクトの規模に関係ないほど小さいことが多いのですが、それでも目を光らせておく必要はあります。サイズの肥大化を回避する方法の一つが、不要なブランチを削除することです。
- 潜在的なパフォーマンス：コアとなるコードが高性能であっても、ブランチが高性能でない可能性があります。このため、オープンブランチは最小限にとどめたいところです。そうしないと、プロジェクトの段階を踏んで調整するまでの間、チームにとってのパフォーマンスの低下を招く可能性があります。
後で説明するように、ローカルブランチに対してgit deleteを実行するのは、ほとんどの場合、簡単な作業になります。しかし、このコマンドを使うと、ブランチに関連するものがすべてリポジトリから消去されるわけではないので、このコマンドを使うときに、実際に何が起こるかを理解しておくことをおすすめします。
Gitローカルブランチを削除するとどうなるのか
技術的な話になりますが、ブランチは特定のコミットを指し示すものにすぎず、言うなればメインブランチに含めるコードのセクションです。そのため、ローカルのGitブランチを削除してもコミットはそのまま残ります。
後ほど、ブランチリカバリについて、そしてそのコミットがレポジトリに残っているからこそ可能なことについてお話します。今のところ、変更には2つの種類があることを覚えておいてください。
- マージするもの：ブランチをメインブランチにマージすると、コードはできるだけ最新の状態になります。技術的に言えば、メインブランチのリファレンスを移動しセカンダリブランチを追うようなものです。
- マージしないもの：変更をマージしない場合、メインブランチと比較して最新でないブランチが1つ存在することになります。そのため、メインブランチには最新の参照コミットが存在しないことになります。
この点については、後で詳しく説明することにします。いずれにせよ、ブランチを削除するタイミングに関係する話でもありますので、このまま続きをご覧ください。
ローカルブランチを削除するタイミング
マージされていない変更のあるブランチを削除してしまう危険性があるため、コードのマージを行うまではローカルブランチでgit deleteを実行しないようにすることが重要です。そうすることで、どのブランチにも最新のリファレンスがあり、ひいては利用可能な最新のコードが確保されます。
また、git deleteを実行する前に、一時ブランチ内のコミットが不要であることを確認しておくことを推奨します。ある程度はブランチの復元をすることができますが、あまり実行したい作業ではありません。これについては、後ほど説明します。
Gitローカルブランチを削除する方法
ここからは、ローカルブランチ上でgit deleteを実行する方法をご紹介します。マージされていない変更をどうするかについても解説します。
ここから、表示される可能性のあるエラーについて、そして削除されたローカルブランチを復元する方法について説明します。
最後に、リモートブランチについて簡単に説明し、その削除方法にも触れます。
前提条件
Git自体はシンプルなコマンドを提供するもので、これには多くの性能が備わっています。それでも、Gitリポジトリにアクセスする方法は、選んだアプリやコードエディタによって変わります。
GitKrakenやSublime Mergeのような専用のGUIでクリック操作することもできますが、ここではシンプルに、OSに組み込まれているツールを使用することにします。
読み進めるには、以下のものが必要になります。
- コマンドラインが使えること：この例では、macOSとiTermを使用します。しかし、WindowsのCmder、macOSのデフォルトのターミナル、Linuxのそれなどを使用することができます。
- 特定のファイルへのアクセス：プロジェクトファイルがないと、何もできないので、ローカルコンピュータに置いておきましょう。
- コマンドラインの知識：コマンドラインの知識があると便利です。具体的には、ファイルを移動するコマンドや、コマンドラインがどのように動作するかをある程度理解している必要があります。
実際には、Gitリポジトリがあるプロジェクトと、お好みのターミナルウィンドウがあれば、これだけで十分です。
基本的な削除コマンドの実行
まず最初に、変更をマージ済みのブランチを削除したいと仮定します。これは最もわかりやすく、典型的なやり方です。
ただし、git branch -aまたはgit branch --listを実行して、すべてのブランチを表示し、リポジトリ内の対象のブランチ特定が必要になる場合があります。
ブランチの削除に必要なコマンドはこちらです。
git branch -d branch-nameブランチ名は、プレースホルダーではなく、実際のブランチ名を使用します。
ここでの-dフラグは「delete」の略で、小文字にすることで、マージされていない変更のあるブランチを削除してしまうことをある程度防ぐことができます。
マージされていないブランチを削除しようとすると、エラーが表示されます（実際には、警告に近いのですが）。
一方で、-D（大文字）にすると、この警告をスキップすることができます。これにより、マージされていない変更のあるブランチを削除可能です。
なお、大文字の場合はブランチを削除するかどうかの確認が取れないので、注意して使う必要があります。
ブランチを削除できないエラーの原因
リポジトリのブランチを削除することは、簡単には解決できない大きな決断なので、Git は間違った動作を検知しエラーを返します。
例えば、ローカルブランチでgit deleteを実行しても、「Cannot delete branch（ブランチを削除できません）」というエラーが表示されることがあります。
この原因は単純です。Gitリポジトリ内の位置に問題があります。「チェックアウト」した（切り替え、有効になっている）ブランチを削除することはできません。
これの解決策は、別のリポジトリに移動することです。
このため、常にmainブランチにチェックアウトしておくことをお勧めします。そうすれば、mainを削除しようとするとエラーが発生します。また、リポジトリ内の他のブランチをすべて削除することも可能です。
削除したGitローカルブランチを復元する方法
ローカルブランチを削除してもコミットが残ることを考えると、git deleteを実行した後にブランチを回復する機会は、わずかですがあります。とは言え、変更をマージするよりも面倒な作業になります。そのような状況では、そもそもブランチが必要ないという結論にいたるかもしれません。
各コミットにはハッシュ番号が付され、そのハッシュ番号は参照として機能します。そのハッシュを使い、チェックアウトしたり新しいブランチを作ったりできます。
ちなみに削除されたブランチのハッシュがわからない場合は、reflogコマンドを使用することができます。このような参照ログは、DevKinstaなどのアプリで目にするものとよく似ています。
git reflogを使う話はまた別の記事で紹介しますが、基本的な機能を使って古いコミットのハッシュを見つけることができます。git reflogを実行すると、コミットのリストが表示されます。
このハッシュの最初の列で、コミットをチェックアウトして新しいブランチを作成することができます。たとえば、以下のようになります。
git checkout 5744ff6git branch f9d2db5しかし、これはGitで削除されたブランチを復元する確実な方法とは言えません。
場合によっては、reflogにコミットがなく、コミット自体へのHEADの参照もないことがあります。このため、ローカルブランチでgit deleteを実行する前に変更をマージし、より安全にブランチを扱うことをおすすめします。
Gitリモートブランチの操作
ローカルブランチでのgit delete実行時には、多くの場合、関連するリモートリポジトリが存在するものです。例えば、Gitを使ってKinstaにサイトをプルダウンするケースなどが挙げられます。
変更を加えてもローカルリポジトリに更新が反映されません。ローカルブランチを削除する際にも同じことが言えます。
GitHubとGitLabのどちらも、リモートのGitブランチを削除するプロセスは同じです。他の一般的なアップストリームへのプッシュと同じような手法になります。
コマンドは以下の通りです。
git push remote-name -d remote-branchremote-nameについて言えば、ほとんどのリポジトリで「origin」が使用されます。remote-branchの参照は、ローカルブランチと同じになります (ローカルブランチの名前を変更[※この記事の説明範囲外です]しない限り)。
余談ですが、git branch -aを使うと、ローカルとリモート両方のブランチをすべて見ることができます。リモートブランチだけを見るには、git branch -rを使用します。
コマンドを実行すると、確認メッセージが表示されます。その後、git branch -aを再度実行して、すべてが操作通りに削除されていることをチェックしてください。
まとめ
Gitは、理解しやすく直感的なコマンドで、多彩な機能を発揮する数少ないツールのひとつです。これは、ローカルマシンで不要になったブランチを削除する際にも同様です。しかし、ローカルブランチでのgit delete実行には注意が必要です。
というのも、マージされていない変更を削除しようとすると、エラーが発生するか、今後のプロジェクトの作業に影響を与えるものを削除してしまう可能性があります。さらに、リモートブランチも削除する必要性が生じます。ローカルとリモートの両方のリポジトリで、パフォーマンスを高く保ち、ファイルサイズを最小限にするために、確実に整理整頓を行う必要があります。
Gitブランチを誤って削除してしまった場合は自己責任となりますが、Kinstaではアプリケーションホスティングという面で、お客様をサポートしています。Kinstaのホスティングプラットフォームでは、わずか数分でGitHubのリポジトリに接続しデプロイすることが可能です。さらに、GoogleのC2マシンやプレミアムティアネットワーク、Cloudflare統合を利用し、アプリケーションのスピードとセキュリティを次のレベルに引き上げます。
