GitHubブランチを削除する方法は?
公開: 2021-07-27必要のないときに何かを破壊することは必須です。
それは新しいもののためのより多くのスペースを作成し、私たちが残りのものを簡単に維持することを可能にします。 そこで、今日はGitHubでブランチを削除するさまざまな方法を検討します。
枝は開発者への神の贈り物のようなものです。 あなたが開発者なら、あなたは私が何を意味するか知っています。 ブランチの実際のユースケースに精通している場合は、次のセクションをスキップして、ブランチセクションを削除することができます。 そして、あなたがgit初心者であるか、ブランチに興味があるなら、読み続けてください。
ブランチとは何ですか?
ブランチは、コミットを参照するポインターです。 読書は枝について理解するのに十分ではありません。 ブランチを明確に理解するには、ブランチがどのように機能するかを確認する必要があります。
実際の開発者がプロジェクトでブランチをどのように使用しているかをいくつかの図で見ていきます。 図の各円はコミットを表していることに注意してください。
簡単なリアルタイムシナリオでブランチのワークフローを見てみましょう。
- あなたが製品開発チームで働いているとしましょう。
- ある日、チームリーダーがあなたのところに行き、「ねえ、製品にエラーが発生しました。 それらを修正する必要があります。」
- そしてあなたは「ええ、確かに」と言いました。
- gitcommitは次のようになります。

- マスターブランチで働いていますか?
- もちろん違います。 マスターブランチ自体から作業する場合、将来的に深刻な問題に直面する可能性があります。 いつかそれがどのように起こるかを示します。
- ここで、バグを修正するためにマスターブランチから別のブランチを取得することにしました。 両方のブランチは、現在のところ同じブランチを指します。

- あなたはバグ修正に取り組み始め、5つのコミットを行いました。 したがって、新しいブランチは次のように進みます。

- 新しいブランチはC8コミットを指していますが、マスターブランチはC3コミットを指しています。
- 今、驚くべきことが起こります。 あなたのチームは再びあなたにつながり、「ねえ、私たちは製品に重大なバグがあり、すぐに修正する必要があります」と言います。
- ふぅ! それは沢山。
- あなたはすでにバグ修正に取り組んでいます。 今、以前のものよりも最も優先度の高いものがたくさんあります。
- したがって、新しいバグを修正するには切り替える必要があります。
- 今まで書いたコードはどうですか?
- 以前のバグを修正するために新しいブランチを作成したので、まったく問題はありません。 これまでに作業しているすべてのコードは、バグ修正ブランチに含まれます。
- ここで、マスターブランチに切り替えて、 critical-bug-fixという別の新しいブランチを作成し、新しいバグ修正の作業を開始します。

- 以前のバグ用に新しいブランチを作成していないと仮定しましょう。 どう思いますか?
- 以前のバグ用に記述されたすべてのコードを削除して、新しいバグの作業を開始する必要があります。 そして、以前のバグのために、いつかすべてのコードを書き直す必要があります。
- これは私たちが話している正確な問題です。
- したがって、ブランチはコードを独立して開発するのに役立ちます。
- これで、新しいバグを修正してコミットするためのコードをいくつか作成しました。

- これで、新しいバグの修正が完了しました。
- これで、以前のバグブランチに切り替えて、作業を開始しました。
だから、あなたはブランチの助けを借りて物事を非常に注意深く管理しています。 混乱はありません。 枝のようなものがなければ、私たちが入る状況を想像してみてください。
したがって、ブランチについての結論は明らかです。 彼らは私たちのような開発者にとって恩恵です。
さらに面倒なことはせずに、ブランチを削除する方法を見てみましょう。
Gitクライアントを使用してブランチを削除する
ブランチの削除について話しているときは、ローカルおよびリモートでブランチを削除しています。 したがって、同じブランチを2回削除するときに、混乱しないでください。 ブランチを削除する手順を見てみましょう。
- ターミナルまたはcmdを開き、gitリポジトリに移動します。
- コマンド
git branch -aして、リポジトリに存在するブランチを確認します。 ローカルブランチとリモートブランチの両方が表示されます。

- 削除するブランチ名をコピーします。 上記の場合、それは1つです。
- マスターブランチ、メインブランチ、または削除ブランチではないその他のブランチにチェックアウトします。
-
git branch -d branchNameして、ブランチをローカルで削除します。branchNameを実際のブランチ名に置き換えます。

git branch -aコマンドでブランチを確認します。 削除されたブランチは、リモートで削除されていないため、引き続きリモートで見つかります。

- リモートのブランチを削除するには、コマンド
git push remoteName -d branchName実行します。remoteNameとbranchNameを適切な名前に置き換えます。

- ブランチをリモートで削除するためのショートカットコマンドがあります。 コマンドは
git push remoteName :branchNameです。
ここで、ブランチを再確認します。 上記の手順を正しく実行した場合、ローカルとリモートの両方で削除されたブランチが見つかりませんでした。


存在しないブランチを削除しようとすると、ブランチが見つかりませんというエラーメッセージが表示されます。

それでおしまい; ローカルとリモートの両方でブランチを正常に削除しました。
GitHubWebアプリを使用してそれを行うには少し異なる方法があります。
見てみようよ。
Webを使用してブランチを削除する
前の方法と今回の方法に大きな違いはありません。 ここでは、GitHubWebアプリを使用してリモートブランチを削除します。 そして、上記の方法で削除するので、ローカルブランチを削除します。
GitHubWebアプリを使用してリモートブランチを削除する方法を見てみましょう。
- GitHubに移動します。
- あなたのアカウントにログイン。
- ブランチを削除するリポジトリに移動します。

- ブランチボタンをクリックして、リポジトリのすべてのブランチを表示します。

- リポジトリのブランチが表示されます。
- また、最後に削除アイコンが表示されます。

- 削除アイコンをクリックして、リモートのブランチを削除します。

- [復元]ボタンをクリックすると、ブランチを復元できます。 ページを更新または閉じるまで利用できます。

これで、リモートのブランチを削除しました。 ローカルリポジトリに移動し、最初の方法で見たコマンドを使用してブランチを削除します。
次に、コマンドgit branch -aを実行して、すべてのブランチを確認します。

削除されたリモートブランチはまだリストに表示されています。 それは何です? どうすれば解決できますか? 職場でこの種の状況に陥る以下のシナリオを参照してください。
あなたがチームで働いていると仮定しましょう。 チームリーダーは、特定のタスクが実行されたときにリモートブランチを削除しました。 どうやってそれを知っていますか? リモートで削除されたブランチについて知る方法はありますか?
削除されたブランチに関するローカルリポジトリとリモートリポジトリを同期する必要があります。 それを行うための特定のコマンドがあります。 彼らです
git remote prune remoteName git fetch -p remoteName -pは、2番目のコマンドでpruneするためのショートカットです。 上記の両方のコマンドのpruneオプションは、リモートへの参照を削除します。


次に、コマンドgit branch -aを実行して、ブランチリストを確認します。

リモートブランチがリストに表示されていないことがわかります。 ただし、ローカルブランチはまだ存在しています。 そうですよ。 問題ありません。 保持または削除できます。
したがって、ローカルに存在するリモートに存在しないブランチを確認してください。 リモートで削除されたローカルブランチを削除します。
あなたの枝は今きれいです。 そして、あなたは行ってもいいです。
結論
ほとんどの場合、git操作にはターミナルまたはcmdを使用します。 そして、それは便利です。 ただし、必須ではありません。 一日の終わりまでに、それは個人的な好みです。
どのツールや方法を使用しても、結果は同じです。 使いやすいものを選択し、それに従ってタスクを完了します。ブランチを削除するには2つの手順を実行します。 ローカルおよびリモートで削除します。
次に、GitHubリポジトリを削除する方法を学びます。
幸せな開発
