关于git fetch -p，它的行为在git 1.9中发生了变化，只有git 2.9.x/2.10反映了这一点。

参见Jeff King (peff)提交9e70233(2016年6月13日)。 (由Junio C Hamano—gitster—在提交1c22105中合并，2016年7月6日)

取回:在取回之前进行修剪的文档 这在10a6cc8中被改变了(fetch——prune:在取回之前运行prune, 2014-01-02)，但似乎在那个讨论中没有人意识到我们明确地宣传了“after”。

所以现在文档声明:

在获取之前，删除远程上不再存在的任何远程跟踪引用

这是因为:

当我们有一个远程跟踪分支命名为“frotz/nitfol”从以前的获取，而上游现在有一个分支命名为“frotz”，获取将无法删除“frotz/nitfol”与“git获取-修剪”从上游。Git会通知用户使用“Git远程修剪”来解决这个问题。 通过在抓取操作之前移动修剪操作来改变“fetch -prune”的工作方式。这样，它就会自动修复冲突，而不是警告用户发生冲突。

关于git fetch -p，它的行为在git 1.9中发生了变化，只有git 2.9.x/2.10反映了这一点。

参见Jeff King (peff)提交9e70233(2016年6月13日)。 (由Junio C Hamano—gitster—在提交1c22105中合并，2016年7月6日)

取回:在取回之前进行修剪的文档 这在10a6cc8中被改变了(fetch——prune:在取回之前运行prune, 2014-01-02)，但似乎在那个讨论中没有人意识到我们明确地宣传了“after”。

所以现在文档声明:

在获取之前，删除远程上不再存在的任何远程跟踪引用

这是因为:

当我们有一个远程跟踪分支命名为“frotz/nitfol”从以前的获取，而上游现在有一个分支命名为“frotz”，获取将无法删除“frotz/nitfol”与“git获取-修剪”从上游。Git会通知用户使用“Git远程修剪”来解决这个问题。 通过在抓取操作之前移动修剪操作来改变“fetch -prune”的工作方式。这样，它就会自动修复冲突，而不是警告用户发生冲突。

如果git fetch -p origin因为某些原因不起作用(比如因为原始repo不再存在或者你无法到达它)，另一个解决方案是删除存储在本地分支上的信息，从repo的根执行:

rm .git/refs/remotes/origin/DELETED_BRANCH

或者如果它存储在文件.git/ packages -refs中，则删除相应的行，如

7a9930974b02a3b31cb2ebd17df6667514962685 refs/remotes/origin/DELETED_BRANCH

您需要完成以下操作

git fetch -p

为了同步你的分支列表。git手册说

- p,修剪 获取后，删除远程上不再存在的任何远程跟踪引用。如果仅仅因为默认的标记自动跟踪或由于——Tags选项而获取标记，则不受修剪的影响。但是，如果由于显式的refspec(在命令行上或在远程配置中，例如如果远程是用——mirror选项克隆的)而获取标记，那么它们也会受到修剪。

我个人喜欢使用git fetch origin -p——progress，因为它显示了一个进度指示器。

这对我很管用。

git remote update --prune

您需要完成以下操作

git fetch -p

-p或——prune参数将更新远程分支的本地数据库。