假设我们有一个稳定的应用程序。
明天，有人报告了一个大漏洞，我们决定立即进行热修复。因此，我们为“master”创建了一个修复分支，我们将其命名为“2011_Hotfix”，并将其推高，以便所有开发人员可以协作修复它。
我们修复了这个错误，并将“2011_Hotfix”合并到“master”以及当前的开发分支中。然后按“主键”。
我们现在对“2011_Hotfix”做什么?它是应该永远作为一个分支存在，直到时间的尽头，还是我们现在应该删除它，因为它已经达到了它的目的?让分支到处乱放似乎是不干净的，因为分支列表可能会变得很长，其中大多数甚至不再需要了。
如果它被删除，它的历史会发生什么?即使实际的分支不再可用，它也会得到维护吗?另外，如何删除远程分支?
当前回答
如果它被成功地合并回来，甚至可能被标记，那么我会说它已经没有任何用处了。你可以安全地执行git branch -d branchname。
其他回答
由于问题有“github”标签，我还会添加这个:特别是在github中，如果你拉请求一个分支，它被合并(无论是通过UI还是合并拉请求的分支)，你不会失去拉请求数据(包括评论)，即使你删除了分支。
这样做的结果是:如果您将拉取请求作为工作流的一部分(它与代码审查巧妙地混合在一起)，那么只要合并分支，您就可以安全地删除它们。这是如此普遍，最近Github增加了一个(甜蜜的)功能，弹出一个“删除分支”按钮后，你合并一个拉请求。
但是值得注意的是，每个组都应该采用最适合自己的工作流(它可能导致也可能不会导致删除这些分支)。例如，我目前的工作团队，只要他们的pull请求被合并，就会删除所有与主节点或部署无关的分支(例如，生产、staging等)，并且我们仍然可以完全跟踪相关的提交如何形成每个产品的每次增量改进。
Of course no history management (pull requests or otherwise) replaces proper tagging of versions (which you preferably automate with the same tool/script that deploys/packages a version), so you can always fast-switch to whatever your users happen to be on at a given moment. Tagging is also the key to solve your original problem: if you establish that any branch merged to the "work" branches can and should be deleted, and that any one that is merged to a version tag, "production", etc. should not, you'll always have the hotfixes alive until they are integrated in a future version.
你需要做的是标记你释放的任何东西。在你积极开发的时候保留分支。
删除旧的分支
git branch -d branch_name
将它们从服务器中删除
git push origin --delete branch_name
或者旧的语法
git push origin :branch_name
它读起来是“在原点上将任何东西推入branch_name”。
也就是说，只要DAG(有向无环图)可以指向它，提交就会在历史记录中出现。
谷歌的“git-flow”，这可能会提供更多关于发布管理、分支和标签的见解。
如果它被成功地合并回来，甚至可能被标记，那么我会说它已经没有任何用处了。你可以安全地执行git branch -d branchname。
你可以删除分支在所有主要的web ui，如github, BitBucket。在线删除分支后，可以使用
git remote prune origin
如果你想修剪已经从原点删除的本地分支，你也可以使用git fetch进行修剪
git fetch --prune
