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

【问题标题】：Is there any reason to not set 'git fetch' to always use the --prune option?是否有任何理由不将 'git fetch' 设置为始终使用 --prune 选项？
【发布时间】：2017-02-13 04:29:19
【问题描述】：

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

git config --global fetch.prune true

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

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

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

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

【问题讨论】：

如果您删除了分支，当您的同事发现他们错误地删除了一个分支时，您不能将它们用作备份。
如果它是一个足够重要的分支，本地分支是否足以备份？你为什么要遥控器？如果您在删除遥控器时犯了愚蠢的错误，我认为您不应该指望其他开发人员进行备份。
修剪树枝有什么好处？
如果您自己还没有在该分支上做任何事情，您可能还没有相应的本地分支。如果你对它做了什么，你的本地分支可能已经转移，你可能没有合并来自相应远程分支的最新更改，因为你可能已经推迟了。
@choroba 我个人将很多分支推送到远程机器上，所以我会说它整理了留在其他人机器上的分支数量。我还要说，它还可以让新开发人员知道哪些分支不再相关或不再积极开发，而无需定期运行“git fetch --prune”（初学者会感到困惑）。使用 git config 你有一个一劳永逸的命令。

标签： git git-remote git-fetch

【解决方案1】：

从根本上说它并不危险，我一直想在自己的 --global 设置中设置它，但我从来没有这样做过：主要是因为它对我的价值也相对较小。¹

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

如果有人错误地删除了上游存储库上的zorg，并且所有下游副本都修剪了它们的origin/zorg，那么您将丢失提交的ID（可能还有许多提交本身）那是上游存储库中zorg 的提示。所以它放大了一些错误的影响。（当然，如果上游存储库如此重要，那么您可能无论如何都应该进行备份 - 尽管如果您选择使用克隆作为备份，自动修剪在那里有一个缺点。当然，您可以随时禁用自动修剪专门针对这些备份。）
假设您确实有自己的 zorg 正在跟踪 origin/zorg，并且上游 zorg 被删除（这次是故意的）。请注意，您的origin/zorg 为您提供git status 信息，告诉您在origin/zorg 之前提交了多少次。假设您现在想移动这些提交，但不希望将这些提交（但不提交用于上游的提交）移动到您自己的另一个分支。在这种情况下，自动修剪您自己的 origin/zorg 使得很难分辨哪些提交是您的，哪些已经在上游。

请注意，在情况 2 中，您不会丢失任何提交。你失去的是能够告诉你的能力，例如，当前在你的zorg 上的最后三个 提交是你自己的，在此之前有几个（现在不在任何其他分支上）最初是一直在origin/zorg。

¹多年来，修剪代码有时会被破坏，主要是因为修剪失败。这意味着 Git 开发人员自己可能不会经常使用它（但现在情况应该会更好，因为现在 Git 的内部测试套件中有测试，以确保修剪在新版本中正常工作）。所以在“低价值”和“过去测试不足”之间，至少在当时，有足够的理由不设置它。

【讨论】：

出于您列出的第二个原因，仅将特定提交移动到另一个分支，我有点困惑您的意思。如果您的其中一个提交依赖于之前所做的提交（那些上游），那么这些更改/提交是否应该随顺？
@timfoil：如果你依赖可能——但也许有人删除上游分支的原因是那些提交被破坏并且不应该被使用，也许你毕竟不要依赖它们（或不依赖它们）。
由于 git 提交可以被认为是一种链表/树的结构，我认为在错误提交之后所做的任何提交都将相互依赖。但是，由于您使用斜体 depend 我认为您是说提交并不总是依赖于先前的提交（可能编辑不同的文件或同一文件的不同部分将是独立的提交）和任意的提示分支可以移动到另一个任意分支吗？什么命令会做这个操作？我猜不要合并，因为这将包括错误的提交。可能会变基？
更准确地说，提交中的父 ID 充当出边（单向弧）。将提交 ID 视为节点（或顶点），将父 ID 视为有向边，我们得到一个有向图，Git 保证它也是无环的。因此提交形成一个 DAG。但是，每个提交都有自己的tree 对象，其中包含源提交时的完整快照。 git cherry-pick 通过将快照与其父级进行比较（对于合并，您必须指定 which 父级）将快照转换为变更集，git rebase 本质上是一系列精选。因此，是的，主要是变基。