安定したアプリケーションがあるとします。
明日、誰かが私たちがすぐに修正プログラムを実行することにした大きな古いバグを報告します。そのため、「master」からそのホットフィックスのブランチを作成し、「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は、プルリクエストをマージした直後に「ブランチの削除」ボタンをポップする（甘い）機能を追加しました。
ただし、各グループが最適なワークフローを採用する必要があることに注意してください（そのようなブランチの削除につながる場合とそうでない場合があります）。たとえば、私の現在の作業チームは、プルリクエストがマージされるとすぐに、マスターまたはデプロイメントに関連しないすべてのブランチ（たとえば、本番、ステージングなど）を削除しますが、関連するコミットがどのように形成されたかを完全に追跡できます。各製品の各段階的な改善。
もちろん、履歴管理（プルリクエストなど）がバージョンの適切なタグ付けに取って代わることはありません（バージョンをデプロイ/パッケージ化するのと同じツール/スクリプトで自動化することが望ましい）ので、ユーザーがたまたま行っているものにいつでもすばやく切り替えることができますある瞬間に。タグ付けは、元の問題を解決するための鍵でもあります。「作業」ブランチにマージされたブランチは削除でき、削除する必要があり、バージョンタグ、「本番」などにマージされたブランチは削除しないようにする必要があります。 、将来のバージョンに統合されるまで、修正プログラムは常に有効です。
ブランチを削除することの欠点は、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」という意味の1語または2語のコマンドはありません。gitただし、この動作はシェルスクリプトを介して模倣できます。たとえば、ZachHolmanのシェルスクリプト「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つまり、単純なマージで履歴が失われることはありません。
追加する言葉がもう1つありますが、それはおそらくあなたの質問の範囲を超えていますが、それでも関連性があります。;に20個の小さな「進行中の」コミットがあると想像してみましょう2011_Hotfix。ただし、の履歴2011_Hotfixに追加する完全なコミットは1つだけにする必要があります。master20個の小さなコミットすべてを1つの大きなコミットにどのように組み合わせるのですか？幸い、をgit使用して、複数のコミットを1つのコミットに統合できますgit-rebase。ここでは、それがどのように機能するかについては説明しません。ただし、興味がある場合は、のドキュメントgit-rebaseが優れています。履歴を書き換えることに注意してくださいgit rebase。特に、初めて使用する場合は、慎重に使用する必要があります。最後に、2011_Hotfixシナリオは開発チームに関するものであり、単独の開発者に関するものではありません。プロジェクトチームメンバーが使用する場合git rebase、チームの一部のカウボーイ開発者がプロジェクトの履歴git rebaseに無意識のうちに損害を与えないようにするために、チームが使用に関する明確なガイドラインを用意することは賢明です。git
それが正常にマージされ、タグ付けされていれば、もう役に立たないと思います。だからあなたは安全に行うことができますgit branch -d branchname。
元の場所から削除されたローカルブランチを整理する場合は、を使用しながら整理することもできます。git fetch
git fetch --prune
github、BitBucketなどのすべての主要なWebUIでブランチを削除できます。オンラインでブランチを削除した後、を使用してローカルブランチを削除できます
git remote prune origin