合并后在本地删除分支是一个好习惯吗？

Question

我刚刚看到我的一位队友这样做，所以想知道他为什么要这么做。这是一个好的做法吗？如果是这样，那是为什么？

这不是会让上游更容易发生分支名称冲突吗？

Answer 1

首先，是这是现在的最佳实践，为什么这是一个问题。

基本上，如果分支的目的是修复错误并且它已经服务了它，那么保留它就没有意义了。删除分支将帮助您保持本地干净。现在，如果分支的目的是添加新功能，那么您可能希望保留它来修复以后发现的有关同一功能的任何错误（理想情况下您仍然应该创建新分支）。但话说回来，一旦目标实现了，坚持下去还有什么意义呢？

简单来说，没有强制删除分支，但不删除就会让事情变得困难和复杂，仅此而已。

此外，如果您想了解更多信息，请查看此博客。

Answer 2

由各个开发者决定是否要在本地删除其分支。 人们可能想要这样做有一些原因：

• 如果您只有活动分支，选项卡补全、UI 分支列表以及其他编辑器和 shell 功能将会更好地工作。
• 仅保留未合并的分支可以轻松查看正在进行的工作。

如果您更喜欢保留较旧的分支以保留您工作的历史记录，或者只是懒惰而不想考虑删除它们，那也可以。

然而，从共享存储库中删除它们是最佳实践。 这是因为默认情况下获取和推送会查找整个引用列表。 如果有很多很多引用，那么传输它们所需的时间和带宽可能会很大，并且 Git 在确定要下载的内容时也会尝试考虑所有这些引用，以尝试发送最小量的数据。 发送少量重复数据通常比获取最小的包文件进行传输更快。

此外，上面提到的所有 UI 优点都与大型共享存储库相关，您可能希望在其中快速找到分支或标签。 即使您不使用这些功能，使用这些功能的合作者也会感谢您的考虑。

通常，您会在合并时删除

Answer 3

上的分支，因为保留它们是不必要的，只会增加噪音和混乱。您可以决定是否还要删除您曾经签出但不再位于服务器上的本地分支。一般来说，我更喜欢删除它们，因为如果我没有自己的新提交，就没有必要保留它们。

关于您的补充问题：

这不是更容易发生分支名称冲突吗？

不完全是；一旦在远程删除了分支，再次重新使用分支名称是完全合理的。特别是对于 Git Flow 中使用的一次性分支，例如“merge-release-into-develop”。该分支可能会被一遍又一遍地创建、合并和删除。

作为旁注，这里有一些轶事证据说明为什么跟上它并删除不需要的本地分支是个好主意。我最近买了一台新的工作笔记本电脑并克隆了该存储库。我一直在跟上，目前当地只有3家分店。不久之后，我意识到我在我的旧笔记本电脑上提交了一些尚未推送的代码。因此，我将存储库从旧笔记本电脑复制到新笔记本电脑上。在那个仓库中，我有 112 个本地分支机构！我估计这些分支中至少 75% 已经被合并并且可以安全地删除，另外 15% 永远不会被合并并且也可以被删除，但我不愿意清除任何分支，直到我有时间找出我可以删除哪些。回想起来，我希望我能跟上它。我可能会随身携带该存储库的副本一段时间。