我们目前正在使用 Git，我们的一位开发人员想要从我们的存储库中删除旧分支。这个请求的原因是'管家'。
我来自 SVN 背景，并不精通 Git，但根据我使用 SVN 的经验，您从不删除分支；这是从第一天开始的经验法则。
在 SVN 中删除一个分支没有任何好处，因为它的大小相对较小，并且它可能包含重要的提交/合并信息，如果删除它会完全丢失。而且，从内务管理的角度来看，如果这个分支太难看，它总是可以移动到另一个远离常规工作流程的位置。
有没有人有具体的理由从现代版本控制系统中删除分支？
【问题讨论】：
svnadmin 和 svndumpfilter 对存储库执行重大手术，否则不会真正从 Subversion 存储库中删除任何内容。 你在 SVN 中删除的任何东西将来都可以恢复，删除不再需要的东西并不是一个坏习惯。
标签： git svn version-control branch
Git 中的分支（一般而言）在合并后不再重要。它们仅在指向无法通过任何其他方式访问的唯一提交时才有用。
Git 甚至提供了git branch --merged 记录为
--merged is used to find all branches which can be safely deleted,
since those branches are fully contained by HEAD.
【讨论】：
根据对 S.O 问题的接受答案，"Git - When to Delete Branches"：
You can safely remove a branch with git branch -d yourbranch.
If it contains unmerged changes (ie, you would lose commits by deleting the branch),
git will tell you and won't delete it.
但是，另一位作者确实继续说：
the disadvantage of deleting branches is that you will break any hyperlinks
to those branches on GitHub.
在标题为“Why I don’t like feature branches”的文章中讨论了我发现的关于删除分支的缺点的最大论据之一：
If feature branches are deleted once they are merged into master, where do bug
fixes go? On a new feature branch or on master? There will no longer be an easy way
to find a list of the commits that went into a feature.
文章Git Basics: Cleaning up excess branches 展示了如何自动删除分支并使其变得更快（如果您选择这样做）。
如果您有任何问题，请告诉我！
【讨论】：
any concrete reasons for deleting branches。我引用了 Paul 文章中的一句话，当你删除一个分支时，你应该知道no longer be an easy way to find a list of the commits that went into a feature.。如果他选择删除一个分支，他应该注意这个问题。如果您有任何问题，请告诉我。
我对在 Subversion 中删除过时的分支和标签并不感到内疚。它使/tags 和/branches 目录更干净。而不是数百个分支和标签，可能只会出现几十个。
如果一个分支不再用于主动开发，并且没有人对代码感兴趣，为什么不删除它呢？如果您有一个没有客户正在使用的代码修订版本，并且没有开发人员不再参考，为什么不将其删除？
我通常对分支机构有某种时间基础。一年没有做任何工作？他们是删除的候选人。如果开发人员不再对代码感兴趣，那就出去吧。
在 Subversion 中，没有任何东西永远不会被永久删除，你总是可以找回它：
假设我将标签删除到我们代码的 1.6 版。突然，一大群审计员出现了，要求检查该特定版本的代码。我可以跑：
$ svn log -q -v http://server/repo/tags | less
然后，找到我删除该标签的时间：
------------------------------------------------------------------------
r76229 | smith | 2011-09-01 11:26:47 -0400
Changed paths:
D /tags/1.6
1.6 标签在修订版 76229 中被删除，所以我知道该标签在我的存储库的修订版 76228 中。我可以恢复那个标签：
$ svn cp -r76228 http://server/repo/tags/1.6@76228 http://server/repos/tags/1.6
如果我只想查看这段代码，我可以在不取消删除标签的情况下查看它：
$ svn co -r76228 http://server/repo/tags/1.6@76228
现在审核员可以开始工作并纠缠开发人员并让我束手无策。
【讨论】：
/branches 目录中可能会出现数百甚至数千个分支。这会使开发人员难以找到他们应该使用的正确分支。想象一个过时的分支（允许在 Friendster 个人资料中发布状态）。有工作吗？开发人员需要引用分支吗？如果没有，为什么不删除它？如果担心将来某个时候Friendster 会卷土重来，那么您将需要此代码，没问题。你可以恢复它。
svn log -v -q，并将输出通过管道传输到 less。现在，我可以使用/^ D /branch/branch_name 在less 输出中搜索删除。所需的修订就在这条线的正上方。使用k、^K、^P、y 或^Y 向后移动几行。找到修订后，恢复分支是一个命令。