使用git fetch --prune删除远程计算机上的分支时删除本地远程跟踪分支。使用以下内容将remote.origin.prune设置为true ...
git config --global fetch.prune true
...使用fetch命令总是隐式使用--prune选项。
我正在为我的小组中不熟悉它的一些开发人员整理git的最佳实践/介绍。在建议他们这样做之前，我想确定我知道这不是一种危险的行为。如果发生一些无关紧要的事故，我至少会让他们了解需要注意的事项。
这似乎不是破坏性操作，因为它不会删除任何本地（非远程）分支。如果没有定期指定git fetch --prune或git remote prune，这似乎是一种不构建不再使用的遥控器的好方法。
如果这都是真的，为什么这不是git的默认行为？
答案 0 :(得分：10)
这并非根本危险，而且我一直想把它设置在我自己的--global设置中，但我从来没有：主要是因为它对我的价值相对较小。 1
正如您所注意到的，本质上，一旦origin/zorg上的分支zorg不再存在，目的就是移除origin。由于这对您自己的zorg没有直接影响，如果您有一个，它通常是无害的，并且会使您对远程跟踪分支的看法变得清晰。唯一可能的两个缺点是：
如果某人错误地删除了上游存储库中的zorg，并且所有下游副本都删除了他们的origin/zorg，则会丢失提交的ID（也许许多提交自己）这是上游存储库中zorg的提示。所以它放大了一些错误的影响。 （当然，如果上游存储库非常重要，那么你可能应该进行备份 - 但是如果你选择使用克隆作为备份，那么自动修剪就会有缺点。当然，你可以随时禁用自动剪枝。备份。）
假设您做拥有自己的zorg跟踪origin/zorg，并且上游zorg被删除（有意这次）。请注意，origin/zorg为您提供了git status信息，告诉您origin/zorg之前提交了多少次提交。假设你现在想要移动这些提交，而不是那些用于上游的提交到你自己的另一个分支。在这种情况下，自动修剪您自己的origin/zorg会很难分辨哪些提交是您的，哪些提交已经在上游。
请注意，在案例2中，您不会丢失任何提交。你失去的是能够告诉你，例如，你zorg上当前只有最后三个提交是你自己的，之前有几个（现在不在任何其他分支上）原来是origin/zorg。
1 多年来，修剪代码有时会被破坏，主要是在修剪失败方面。这意味着Git开发人员自己可能不会使用它（但现在应该会更好，因为现在Git的内部测试套件中有测试，以确保修剪在新版本中正常工作）。因此，在“低价值”和“过去的测试不足”之间，至少在当时，有充分的理由不设置它。