什么时候删除Git中的分支?

小开

最佳答案

你可以使用git branch -d yourbranch安全地移除一个分支。如果它包含未合并的更改(例如，删除分支会丢失提交)，git会告诉你，不会删除它。

因此，删除一个合并的分支成本很低，而且不会丢失任何历史记录。

要删除远程分支，请使用git push origin :mybranch，假设您的远程名称为origin，并且您要删除的远程分支名为mybranch。

小开

如果它被成功地合并回来，甚至可能被标记，那么我会说它已经没有任何用处了。所以你可以安全地执行git branch -d branchname。

小开

你需要做的是标记你释放的任何东西。在你积极开发的时候保留分支。

删除旧的分支

git branch -d branch_name

将它们从服务器中删除

git push origin --delete branch_name

或者旧的语法

git push origin :branch_name

它读起来是“在原点上将任何东西推入branch_name”。

也就是说，只要DAG(有向无环图)可以指向它，提交就会在历史记录中出现。

谷歌的“git-flow”，这可能会提供更多关于发布管理、分支和标签的见解。

小开

由于问题有“github”标签，我还会添加这个:特别是在Github中，如果你pull请求一个分支，它被合并(无论是通过UI还是通过合并拉请求的分支)，你不会丢失拉请求数据(包括注释)，即使你去掉了树枝。

这样做的结果是:如果您将拉取请求作为工作流的一部分(它与代码审查巧妙地混合在一起)，那么只要合并分支，您就可以安全地删除它们。这是如此普遍，最近Github增加了一个(甜蜜的)功能，弹出一个“删除分支”按钮后，你合并一个拉请求。

但是值得注意的是，每个组都应该采用最适合自己的工作流(它可能导致也可能不会导致删除这些分支)。例如，我目前的工作团队，只要他们的pull请求被合并，就会删除所有与主节点或部署无关的分支(例如，生产、staging等)，并且我们仍然可以完全跟踪相关的提交如何形成每个产品的每次增量改进。

当然，没有历史记录管理(拉取请求或其他方式)可以取代适当的版本标记(最好使用部署/打包版本的相同工具/脚本自动化)，因此您总是可以快速切换到用户在给定时刻正在使用的任何内容。标记也是解决原始问题的关键:如果您确定任何合并到“工作”分支的分支都可以并且应该被删除，而任何合并到版本标记、“生产”等的分支都不应该被删除，那么您将一直保留这些修复程序，直到它们集成到未来的版本中。

小开

我想补充的是，删除分支的缺点是你会破坏到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，删除本地和远程分支。”但是这种行为可以通过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命令更简单——尽管可能更危险。

你对保护历史的关心是对的。在这种情况下，你不必担心。一旦你将2011_Hotfix合并到master上，所有来自2011_Hotfix的提交都会被添加到master的提交历史中。简而言之，简单的合并不会丢失历史记录。

我还有一句话补充说，这可能超出了你的问题范围，但很有意义。让我们想象在2011_Hotfix上有20个微小的“正在进行中的工作”提交;然而，你只需要将2011_Hotfix的一次完整提交添加到master的历史记录中。如何将所有20个小提交合并为一个大提交?幸运的是，git允许你通过使用git-rebase将多个提交合并为一个提交。我不会在这里解释它是如何工作的;不过，如果你感兴趣的话，2011_Hotfix1很不错。请注意，git rebase重写历史，所以应该明智地使用它，特别是如果你是新手。最后，你的2011_Hotfix场景是关于一个开发团队，而不是一个单独的开发人员。如果项目团队成员使用git rebase，那么团队对git rebase的使用有明确的指导方针是明智的，这样团队中的一些牛仔开发人员就不会在不知不觉中破坏项目的git历史。

小开

你可以删除分支在所有主要的web ui，如github, BitBucket。在线删除分支后，可以使用

git remote prune origin

小开

如果你想修剪已经从原点移除的本地分支，你也可以使用git fetch进行修剪

git fetch --prune