いつGitでブランチを削除するのですか？

安定したアプリケーションがあるとします。

明日、誰かが大きなOLのバグを報告して、すぐにホットフィックスすることにしました。そこで、「マスター」からそのホットフィックスのブランチを作成し、「2011_Hotfix」という名前を付け、それをプッシュアップして、すべての開発者が協力して修正できるようにします。

バグを修正し、「2011_Hotfix」を「master」と現在の開発ブランチにマージします。そして「マスター」を押します。

「2011_Hotfix」で何をしますか？それはその目的を果たしたので、時間の終わりまで永遠にブランチとしてそこに存在するべきなのでしょうか、それとも削除すべきなのでしょうか？ブランチのリストが非常に長くなる可能性が高く、ブランチのリストが非常に長くなるため、ブランチをどこにでも置いておくのは不潔に思えます。

削除する必要がある場合、その履歴はどうなりますか？実際のブランチが利用できなくなっても、それは維持されますか？また、リモートブランチを削除するにはどうすればよいですか？

でブランチを安全に削除できgit branch -d yourbranchます。マージされていない変更が含まれている場合（つまり、ブランチを削除するとコミットが失われる）、gitはそれを通知し、削除しません。

したがって、マージされたブランチを削除するのは安上がりで、履歴が失われることはありません。

リモートブランチを削除するには、を使用git push origin :mybranchします。リモート名がoriginで、削除するリモートブランチの名前がmybranchであると仮定します。

あなたがする必要があるのはあなたがリリースしたものにタグを付けることです。活発に開発しているときのためにブランチを置いておいてください。

古いブランチを削除する

git branch -d branch_name

それらをサーバーから削除します

git push origin --delete branch_name

または古い構文

git push origin :branch_name

これは、「オリジンのbranch_nameに何もプッシュしない」と読みます。

とはいえ、DAG（有向非巡回グラフ）がそれを指すことができる限り、コミットは履歴に残ります。

Googleの「git-flow」を使用すると、リリース管理、ブランチ、タグ付けについてさらに洞察を得ることができます。

質問には「github」タグが付いているので、これも追加します。具体的にはGithubで、ブランチをプルリクエストし、（UI経由で、またはプルリクエストのブランチをマージすることによって）マージされた場合、ブランチを削除しても、プルリクエストデータ（コメントを含む）が失われます。

この結果：プルリクエストをワークフローの一部として組み込むと（コードレビューとうまく調和します）、ブランチがマージされたらすぐに安全にブランチを削除できます。これは非常に一般的であるため、プルリクエストをマージした直後に「ブランチの削除」ボタンをポップする（甘い）機能が最近Githubに追加されました。

ただし、各グループが最適なワークフローを採​​用する必要があることに注意してください（そのようなブランチの削除につながる場合もあれば、そうでない場合もあります）。たとえば、私の現在の作業チームは、プルリクエストがマージされるとすぐに、マスターまたはデプロイメント関連ではないすべてのブランチ（本番、ステージングなど）をプルーニングし、関連するコミットがどのように形成されたかを完全に追跡しています各製品の各増分改善。

もちろん、履歴管理（プルリクエストなど）はバージョンの適切なタグ付け（バージョンをデプロイ/パッケージ化する同じツール/スクリプトで自動化することが望ましい）に置き換わるものではないため、ユーザーが発生しているものにいつでもすばやく切り替えることができます。ある瞬間に。タグ付けは、元の問題を解決するための鍵でもあります。「work」ブランチにマージされたブランチは削除可能であり、削除する必要があることを確立し、バージョンタグ、「production」などにマージされたブランチは削除してはなりません。 、将来のバージョンに統合されるまで、修正プログラムは常に有効です。

ブランチを削除することの不利な点は、GitHub（この質問にはgithubのタグが付けられています）でそれらのブランチへのハイパーリンクを解除することです。あなたは得られます404 Not Foundこれらのリンクのエラーを。これが、GitHubのブランチを削除した後で、リンクをコミットまたはタグを指すように変更する理由です。

メールなどの一部のリンクは変更できないため、GitHubブランチへのハイパーリンクを完全に回避し、初日からコミットまたはタグにリンクします。

私はブランチがマージされた後でブランチを削除することを好みます。これにより、リポジトリ内のブランチの長いリストが視覚的に雑然とするのを防ぎます。これらのブランチは、リポジトリのすべてのフォークにも伝播されます。

まず、ローカルブランチを削除します。これにより、後で誤ってプッシュされるのを防ぎます。

git branch -d branchName

次に、リモート追跡ブランチを削除します

git branch -dr remoteName\branchName

次に、GitHubのブランチを削除します。Webインターフェイスを使用していますが、同等のコマンドを以下に示します。

git push remoteName :branchName

ブランチがマージされない場合でも、通常は後世のためにコミットを維持したいと思います。しかし、私はまだブランチを削除したいです。コミットを広め、ガベージコレクターに食べられないようにするために、削除されたブランチと同じコミットを指す注釈付きタグを作成します。

git tag -a tagName commitOrBranchName

次に、タグをgithubにプッシュします

git push remoteName tagName

2011_Hotfix履歴を失わずにブランチを削除したいようです。最初に削除について、次に履歴について説明します。

通常のgitブランチ削除方法についてはすでに説明済みで、期待どおりに機能します。gitには、「gitローカルブランチとリモートブランチの両方を削除します」という意味の1ワードまたは2ワードのコマンドはありません。ただし、この動作はシェルスクリプトを介して模倣できます。たとえば、Zach Holmanのシェルスクリプト 'git-nuke'を使用します。それは非常に簡単です：

#!/bin/sh
git branch -D $1
git push origin :$1

これを、ディレクトリのgit-nuke1つにある実行可能ファイル（たとえば、）に入れます$PATH。2011_Hotfixブランチにいない場合は、実行git-nuke 2011_Hotfixするとローカルブランチとリモートブランチの両方が削除されます。これは、標準のgitコマンドよりもはるかに高速でシンプルです（おそらくより危険です）。

歴史の保存についてのあなたの懸念は良いものです。この場合、心配する必要はありません。にマージ2011_Hotfixするとmaster、からのすべてのコミットがのコミット履歴に2011_Hotfix追加されmasterます。つまり、単純なマージによって履歴が失われることはありません。

もう1つ付け加えることがありますが、それはおそらくあなたの質問の範囲を超えていますが、それでも関連性があります。20の小さな「進行中の作業」のコミットがあると想像してみましょう2011_Hotfix。ただし、の履歴に2011_Hotfix追加する完全なコミットを1つだけにする必要がありますmaster。20の小さなコミットすべてを1つの大きなコミットにどのように結合しますか？幸いにも、をgit使用して複数のコミットを1つのコミットに統合できますgit-rebase。ここではその仕組みについては説明しません。ただし、興味がある場合は、のドキュメントgit-rebaseが優れています。git rebaseは履歴を書き換えるので、特に初めて使用する場合は慎重に使用してください。最後に、あなたの2011_Hotfixシナリオは、一人の開発者ではなく、開発チームに関するものです。プロジェクトチームのメンバーが使用する場合git rebase、チームのgit rebase一部のカウボーイ開発者がプロ​​ジェクトのgit履歴に意図せず損傷を与えないようにするために、チームがの使用に関する明確なガイドラインを持っていることが賢明です。

正常にマージされ、タグ付けされていたとしても、もう役に立たないと言えます。だからあなたは安全に行うことができますgit branch -d branchname。

originから削除されたローカルブランチをプルーニングしたい場合は、使用中にプルーニングすることもできます git fetch

git fetch --prune

github、BitBucketなどのすべての主要なWeb UIでブランチを削除できます。オンラインでブランチを削除した後、次のコマンドを使用してローカルブランチを削除できます。

git remote prune origin