是否有任何理由不将 'git fetch' 设置为始终使用 --prune 选项？

当远程计算机上的分支已被删除时，使用 git fetch --prune 删除本地远程跟踪分支。使用以下命令将remote.origin.prune设置为true...

git config --global fetch.prune true

...使得使用 fetch 命令总是隐式使用 --prune 选项。

我正在为我的团队中不太熟悉 git 的一些开发人员整理一份最佳实践/介绍。在建议他们这样做之前，我想确保我知道这不是危险行为。我至少会提醒他们，如果发生一些无关的事故，要注意什么。

这似乎不是破坏性操作，因为它不会删除任何本地（非远程）分支。这似乎也是一种很好的方法，可以在不定期指定 git fetch --prune 或 git Remote prune 的情况下，不再构建不再使用的遥控器。

如果这都是真的，为什么这不是 git 的默认行为？

It's not fundamentally dangerous, and I have been tempted to set it in my own --global settings, but I never have: primarily because it also has relatively little value to me.¹

正如您所注意到的，本质上，其目的是删除origin/zorg一次分支zorg不再存在于origin。因为这对你自己没有直接影响zorg，如果您有的话，它通常是无害的，并且会扰乱您对远程跟踪分支的看法。唯一可能的两个缺点是：

1. 如果有人错误地删除zorg在上游存储库上，所有下游副本都会修剪它们的origin/zorg，你会丢失提交的 ID（也许还有许多提交本身），这就是提示zorg在该上游存储库中。所以它放大了一些错误的影响。 （当然，如果上游存储库如此重要，您可能无论如何都应该进行备份 - 但如果您选择使用克隆作为备份，自动修剪就会有一个缺点。当然，您始终可以专门在这些上禁用自动修剪备份。）

2. 假设你do有你自己的zorg那就是跟踪origin/zorg，以及上游zorg被删除（这次是故意的）。请注意，这已经是您的了origin/zorg为您提供git status告诉您提前了多少次提交的信息origin/zorg。假设您现在想要move这些提交（但不是上游的提交）到您自己的另一个分支。在这种情况下，自动修剪你自己的origin/zorg很难判断哪些提交是您的，哪些已经在上游。

请注意，在情况 2 中，你不会丢失任何提交。你失去的是辨别能力，例如，只有最后三目前致力于您的zorg是你自己的，之前有几个（现在不在任何其他分支上）最初是在origin/zorg.

¹Over the years, the pruning code has sometimes been somewhat broken, mostly in terms of failing to prune. This implies that the Git developers themselves probably don't use it much (but things should be better now since there are now tests in Git's internal test-suite to make sure pruning works correctly in new releases). So between "low value" and "insufficient testing in the past", that was, at least at the time, sufficient reason not to set it.