何时删除Git中的分支？
假设我们有一个稳定的应用程序。
明天，有人会报告我们决定马上修复的大问题。 所以我们为这个修补程序创build了一个关于“master”的分支，我们将其命名为“2011_Hotfix”，然后我们将其推上，以便所有开发人员可以协作修复它。
我们修复这个bug，并将“2011_Hotfix”合并到“master”以及当前的开发分支中。 并推“大师”。
我们现在用“2011_Hotfix”做什么？ 它是否应该永远坐在那里作为一个分支直到时间的终点，还是现在我们应该删除它，因为它已经达到了目的？ 看起来不太清楚，只是把树枝搁在四周，因为树枝的名单可能会变得很长，其中大部分甚至不再是必要的。
如果要删除它，它的历史将会发生什么？ 即使实际分支不再可用，这是否会被保留？ 另外，我将如何删除远程分支？
你可以安全地删除一个分支与git branch -d yourbranch 。 如果它包含未合并的更改（即，您将通过删除分支而失去提交），git会告诉您并且不会将其删除。
所以，删除一个合并的分支是便宜的，不会让你失去任何历史。
要删除远程分支，请使用git push origin :mybranch ，假设您的远程名称是源，并且您要删除的远程分支名为mybranch。
你需要做的是标签你发布的任何东西。 当你积极发展的时候保持分支。
删除旧的分支
git branch -d branch_name
从服务器中删除它们
git push origin --delete branch_name
或旧的语法
git push origin :branch_name
其内容如下：“在原始位置不会将任何东西压入branch_name”。
也就是说，只要DAG（有向无环图）可以指向它，这个提交就会在那里发生。
谷歌的“git-flow”，这可能会提供更多的发布pipe理，分支和标签的见解。
由于问题有“github”标签，我还要添加这个：特别是在Github中 ，如果你拉取一个分支并且合并（通过UI或合并pull请求的分支），你不会即使删除分支 ， 也会丢失请求数据（包括注释）。
这样做的结果是：如果您将拉取请求作为工作stream程的一部分（与代码审阅巧妙融合），则可以在合并后尽快删除分支。 这是很常见的，最近Github添加了一个（甜）function，popup一个“删除分支”button之后合并一个拉请求。
但值得注意的是，每个小组都应该采用最适合的工作stream程（并且可能会导致删除这些分支）。 例如，我当前的工作团队，只要合并了他们的请求，就会修剪所有与主或与部署无关的分支（例如，生产，分段等），并且我们仍然完全跟踪相关的提交是如何形成的每个产品的每个增量改进。
当然，没有历史pipe理（拉取请求或其他方式）取代适当的版本标记（您最好使用相同的工具/脚本来部署/打包版本），所以您可以随时快速切换到您的用户碰巧在给定的时刻。 标签也是解决您原有问题的关键：如果您确定任何合并到“工作”分支的分支可以并且应该被删除，并且任何合并到版本标签，“生产”等的分支都不应该，你将永远有修补程序活着，直到他们被集成在未来的版本。
我会补充说，删除分支的缺点是你会打破任何超链接到GitHub上的这些分支（这个问题被标记为github）。 你会得到一个404 Not Found这些链接的错误。 这就是为什么我在GitHub上删除分支后，将链接更改为指向提交或标记的原因。
由于某些链接无法更改，比如在电子邮件中，我现在完全避免超链接到GitHub分支，并从第一天链接到提交或标记。
我更喜欢在合并之后删除分支。这样可以防止存储库中分支的冗长列表的视觉混乱。 这些分支也被传播到所有的版本库。
首先我删除我的本地分支。 这可以防止以后被意外推送。
git branch -d branchName
然后我删除远程跟踪分支
git branch -dr remoteName\branchName
然后我删除GitHub上的分支。 我使用networking界面，但等效命令如下。
git push remoteName :branchName
即使这个分支从来没有合并过，我仍然希望继续为子孙后代作出承诺。 但是我仍然想删除分支。 为了传播提交，并防止它们被垃圾收集器所占用，我做了一个带注释的标签，指向与被删除分支相同的提交。
git tag -a tagName commitOrBranchName
然后我把标签推到github上
git push remoteName tagName
看来你想删除2011_Hotfix分支而不会丢失它的历史logging。 我将首先讨论删除和历史第二。
上面已经描述了通常的git分支删除方法，并且按照预期工作。 git没有一个或两个字的命令，这意味着，“嘿， git ，删除本地和远程分支”。 但是这个行为可以通过shell脚本来模拟。 例如，拿Zach Holman的shell脚本“git-nuke” 。 这很简单：
#!/bin/sh git branch -D $1 git push origin :$1
把它放在一个可执行文件（例如git-nuke ）中放在你的$PATH目录中。 如果你不在2011_Hotfix分支上，你只需运行git-nuke 2011_Hotfix就会同时删除本地和远程分支。 这比标准的git命令更快更简单 – 虽然也许更危险。
您对保存历史的关注是一个很好的select。 在这种情况下，你不必担心。 一旦你将2011_Hotfix合并到master ，所有来自2011_Hotfix提交将被添加到master的提交历史中。 总之，你不会从简单的合并中失去历史。
我还有一句话要补充说，这可能超出了你的问题的范围，但仍然是相关的。 假设在2011_Hotfix上有20个微小的“正在进行中”提交; 但是，您只需要将一个完整的2011_Hotfix提交添加到master的历史logging中。 你如何将20个小提交合并为一个大提交？ 幸运的是， git允许你通过使用git-rebase将多个提交合并成一个提交。 我在这里不会解释这是如何工作的。 不过，如果你有兴趣， git-rebase的文档是非常好的。 请注意， git rebase重写历史logging，所以应该谨慎使用它，特别是如果你是新手的话。 最后，你的2011_Hotfix场景是关于一个开发团队，而不是一个独立开发者。 如果项目团队成员使用git rebase ，那么团队明智地使用git rebase是明智的，这样团队中的一些牛仔开发人员不会在无意中损害项目的git历史。
如果它已成功合并回来，甚至可能被标记，那么我会说它已经没有用了。 所以你可以安全地做git branch -d branchname 。
