Gitでブランチを削除するタイミング
安定したアプリケーションがあるとします。
明日、誰かが大きなバグを報告し、すぐに修正することにしました。そのため、「マスター」からそのホットフィックスのブランチを作成し、「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
「Originでbranch_nameに何もプッシュしない」と読みます。
つまり、DAG（有向非巡回グラフ）がそれを指し示すことができる限り、コミットは履歴に存在します。
Googleの「git-flow」を使用すると、リリース管理、分岐、タグ付けに関する洞察が得られます。
質問には「github」タグがあるので、これも追加します。具体的には Github に、もしあなたpull-requestブランチと（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つのWordコマンドがありません。ただし、この動作はシェルスクリプトを介して模倣できます。たとえば、 Zach Holmanのシェルスクリプト 'git-nuke' を使用します。それは非常に簡単です：
#!/bin/sh
git branch -D $1
git Push Origin :$1
これをgit-nukeディレクトリの1つにある実行可能ファイル（$PATHなど）に入れます。 2011_Hotfixブランチを使用していない場合、単にgit-nuke 2011_Hotfixを実行すると、ローカルブランチとリモートブランチの両方が削除されます。これは、標準のgitコマンドよりもはるかに高速かつ単純です（おそらくより危険です）。
歴史を保存することについてのあなたの懸念は良いものです。この場合、心配する必要はありません。 2011_Hotfixをmasterにマージすると、2011_Hotfixからのすべてのコミットがmasterのコミット履歴に追加されます。つまり、単純なマージで履歴が失われることはありません。
追加するWordがもう1つありますが、これはおそらくあなたの質問の範囲を超えていますが、それでも関連があります。 2011_Hotfixには20の小さな「進行中の」コミットがあると想像してみましょう。ただし、2011_Hotfixの完全なコミットを1つだけmasterの履歴に追加する必要があります。 20個の小さなコミットを1つの大きなコミットにどのように結合しますか？幸い、gitを使用すると、git-rebaseを使用して複数のコミットを1つのコミットに統合できます。ここでは、その仕組みを説明しません。ただし、興味がある場合は、 git-rebaseのドキュメント が優れています。 git rebaseは履歴を書き換えるため、特に初心者の場合は慎重に使用する必要があります。最後に、あなたの2011_Hotfixシナリオは、ソロ開発者ではなく開発者チームに関するものです。プロジェクトチームメンバーがgit rebaseを使用する場合、チームの一部のカウボーイ開発者がプロジェクトのgitの履歴を意図せずに損傷しないように、git rebaseの使用に関する明示的なガイドラインを作成することが賢明です。
正常にマージされ、タグ付けされている場合は、もう使い物にならないと言えます。したがって、git branch -d branchnameを安全に実行できます。
Github、BitBucketなどのすべての主要なWeb UIでブランチを削除できます。オンラインでブランチを削除した後、次を使用してローカルブランチを削除できます。
git remote Prune Origin
Originから削除されたローカルブランチをプルーニングしたい場合は、git fetchを使用しながらプルーニングすることもできます
git fetch --Prune