使用git fetch--prune在删除远程机器上的分支后删除本地远程跟踪分支。使用以下命令将remote.origin.prune设置为true…
git config --global fetch.prune true
…使使用fetch命令始终隐式使用--prune选项。
我正在为我的小组中不太熟悉的一些开发人员编写一个关于Git的最佳实践/介绍。在建议他们这样做之前，我想确定我知道这不是一个危险的行为。我至少要提醒他们，如果发生了一些无关的意外事故，应该注意什么。
这似乎不是一个破坏性的操作，因为它不会删除任何本地（非远程）分支。这似乎也是一种不构建不再使用的远程设备的好方法，而不定期指定git fetch——prune或git remote prune。
如果这都是真的，为什么这不是git的默认行为？
最佳答案
这从根本上来说并不危险，我曾试图将其设置为自己的--global设置，但我从未设置过：主要是因为它对我的价值相对较小。1
正如您所注意到的，其目的本质上是在origin/zorg上不再存在branchzorg时删除origin。由于这对您自己的zorg没有直接影响，如果您有一个，它通常是无害的，并且会破坏远程跟踪分支的视图。唯一可能的两个缺点是：
如果有人错误地删除了上游存储库上的zorg，而所有下游副本都删除了它们的origin/zorg，则会丢失提交的ID（可能还有许多提交本身），这是上游存储库中zorg的提示。所以它放大了一些错误的影响。（当然，如果上游存储库如此重要，那么您可能无论如何都应该进行备份，但是如果您选择将克隆用作备份，那么自动修剪就有一个缺点。当然，您可以在这些备份上禁用自动修剪。）
假设您有自己的zorg跟踪origin/zorg，上游的zorg会被删除（这次是故意的）。请注意，正是您的origin/zorg为您提供了git status信息，告诉您您提前了多少提交。假设您现在希望将这些提交移动到您自己的另一个分支，但不移动以前位于上游的提交。在这种情况下，自动修剪您自己的origin/zorg会使您很难判断哪些提交是您的，哪些提交已经在上游。
注意，在案例2中，您不会丢失任何提交。您所失去的是能够告诉您，例如，当前只有最后三个提交是您自己的，之前的几个提交（现在不在任何其他分支上）最初是在origin/zorg上的。
1多年来，修剪代码有时有点破损，主要是因为无法修剪。这意味着Git开发人员本身可能不会经常使用它（但现在情况应该更好了，因为现在Git的内部测试套件中有测试，以确保新版本中的修剪工作正常）。因此，在“低值”和“过去的测试不足”之间，至少在当时，有充分的理由不进行设置。
关于git - 有没有理由不设置'git fetch'来始终使用--prune选项？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/39861912/