问题描述
在一个大型团队中工作，有许多开发人员。他们有一个庞大的代码库，有许多来自开发人员的功能分支。他们正在积累许多功能分支。
他们通常遵循git-flow的最佳实践。
功能分支应该保留多长时间？
保留所有功能分支是否安全且不会降低性能？
开发人员需要定期执行哪些维护命令来保持工作、高效和响应迅速的git？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
功能分支应该保持到功能完成为止，一旦完成，分支必须关闭/删除。建立这种行为应该是一个团队的目标，通常需要一些时间，因为在快速完成拉取请求的情况下，很容易忘记它们。
保留所有功能分支会增加可维护性的难度。你可能认为每个分支都遵循命名约定，并与JIRA票据或其他映射方式相关联，很容易区分它们，但是一旦你有了十几个分支，甚至更多的分支不断堆积，情况就不是这样了。我非常怀疑性能与此有关，更像是一个混乱成本开关。
至于命令，我不认为有这样的需求。
方案2
我同意Recoba20的回答，并想补充一些内容。
我们通常遵循git-flow的最佳实践。
这意味着：
- 在某个时刻，你也会将这些分支合并到主线（即
master分支）中。 - 你使用
--no-ff标志进行合并。
如果是这种情况，保留这些分支对你的流程没有任何帮助。更改已经完成，如果你需要修复错误或进行更改，这意味着你将从更下游的位置开始一个新的分支，而不是从原始的功能分支开始（根据git-flow的规定）。
我可以想到的一种情况是某种方式上搞砸了主线（或release-X），你需要重新创建一组合并在一起的功能。如果你已经有了这些分支，即没有删除，你可以创建一个新的发布分支，并将正确的功能重新合并进去。如果你没有这些分支，那也不是什么大问题，因为使用--no-ff合并时，合并一个分支时会有一个单独的提交。而且，由于分支只是指向提交的指针，你只需在那个特定的最后一个提交处创建一个分支，就好像你从一开始就没有删除它一样。
关于性能问题，我不确定git本身是否会有问题，因为分支只是引用（指向提交的指针），但同时，某些情况下可能会出现速度慢的情况，比如克隆操作。
我更可能看到的一个问题是一些git图形界面工具的性能下降。对于这种情况，我建议使用一些轻量级的工具；我长期使用过gitk，它非常适合快速查看提交树的概览。
至于维护命令，我只想提一下git branch --no-merged master，它可以列出尚未合并的分支。它不能解决任何问题，但可以让你看到你正在处理的内容。
说了这么多，我建议你更多地思考你的开发流程，并考虑做一些不同的事情。根据我的经验，大多数git问题只是一个流程不太适合意图的症状。git只是在那里，承受着打击。长时间运行（几天、几周）的功能分支使得在集成回主线时更容易遇到问题。
这种情况的替代方法是更频繁地合并和/或使用功能切换。