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