从已删除的远程分支的原点获取?

发布于 2024-11-02 12:45:28 字数 135 浏览 3 评论 0原文

当我执行 git fetch origin 且 origin 有一个已删除的分支时,它似乎没有在我的存储库中更新它。当我执行 git Branch -r 时,它仍然显示 origin/DELETED_BRANCH 。

我该如何解决这个问题?

When I do git fetch origin and origin has a deleted branch, it doesn't seem to update it in my repository. When I do git branch -r it still shows origin/DELETED_BRANCH.

How can I fix this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

浮生面具三千个 2024-11-09 12:45:28

您需要执行以下操作

git fetch -p

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

You need to do the following

git fetch -p

The -p or --prune argument will update the local database of remote branches.

两相知 2024-11-09 12:45:28

来自 http://www.gitguys.com/topics/adding-and-removing-remote-分支/

有人从远程仓库删除分支后,git不会
当用户执行以下操作时自动删除本地存储库分支
git pull 或 git fetch。但是,如果用户想要拥有所有
跟踪从本地存储库中删除的分支
在远程存储库中删除时,他们可以键入:

git 远程修剪源

请注意, git fetch -p 中的 -p 参数实际上意味着“修剪”。

无论您选择哪种方式,不存在的远程分支都将从本地存储库中删除。

From http://www.gitguys.com/topics/adding-and-removing-remote-branches/

After someone deletes a branch from a remote repository, git will not
automatically delete the local repository branches when a user does a
git pull or git fetch. However, if the user would like to have all
tracking branches removed from their local repository that have been
deleted in a remote repository, they can type:

git remote prune origin

As a note, the -p param from git fetch -p actually means "prune".

Either way you chose, the non-existing remote branches will be deleted from your local repository.

望笑 2024-11-09 12:45:28

您需要执行以下操作

git fetch -p

才能同步您的分支列表。 git 手册

-p--prune
获取后,删除远程上不再存在的所有远程跟踪引用。如果仅由于默认标签自动跟踪或由于 --tags 选项而获取标签,则标签不会受到修剪。但是,如果由于显式引用规范(在命令行上或在远程配置中,例如,如果使用 --mirror 选项克隆远程)而获取标签,则它们也会受到影响进行修剪。

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

You need to do the following

git fetch -p

in order to synchronize your branch list. The git manual says

-p, --prune
After fetching, remove any remote-tracking references that no longer exist on the remote. Tags are not subject to pruning if they are fetched only because of the default tag auto-following or due to a --tags option. However, if tags are fetched due to an explicit refspec (either on the command line or in the remote configuration, for example if the remote was cloned with the --mirror option), then they are also subject to pruning.

I personally like to use git fetch origin -p --progress because it shows a progress indicator.

无声无音无过去 2024-11-09 12:45:28

这对我有用。

git remote update --prune

This worked for me.

git remote update --prune
手长情犹 2024-11-09 12:45:28

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

请参阅 提交 9e70233(2016 年 6 月 13 日),作者:杰夫·金 (peff)
(由 Junio C Hamano -- gitster -- 合并于 提交 1c22105,2016 年 7 月 6 日)

fetch:在获取之前进行修剪的文档

这已在 10a6cc8 中更改(fetch --prune:在获取之前运行 prune,2014-01-02),但在那次讨论中似乎没有人意识到我们正在明确宣传“之后”。

所以文档现在指出:

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

这是因为:

当我们在之前的 fetch 中有一个名为“frotz/nitfol”的远程跟踪分支,并且上游现在有一个名为“frotz”的分支时,fetch 将无法使用“git fetch --prune”从上游删除“frotz/nitfol”。 git 会通知用户使用“git Remote prune”来解决问题。

通过将修剪操作移到获取操作之前来更改“fetch --prune”的工作方式。这样,它就不会警告用户存在冲突,而是会自动修复冲突。

Regarding git fetch -p, its behavior changed in Git 1.9, and only Git 2.9.x/2.10 reflects that.

See commit 9e70233 (13 Jun 2016) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit 1c22105, 06 Jul 2016)

fetch: document that pruning happens before fetching

This was changed in 10a6cc8 (fetch --prune: Run prune before fetching, 2014-01-02), but it seems that nobody in that discussion realized we were advertising the "after" explicitly.

So the documentation now states:

Before fetching, remove any remote-tracking references that no longer exist on the remote

That is because:

When we have a remote-tracking branch named "frotz/nitfol" from a previous fetch, and the upstream now has a branch named "frotz", fetch would fail to remove "frotz/nitfol" with a "git fetch --prune" from the upstream. git would inform the user to use "git remote prune" to fix the problem.

Change the way "fetch --prune" works by moving the pruning operation before the fetching operation. This way, instead of warning the user of a conflict, it automatically fixes it.

救赎№ 2024-11-09 12:45:28

对于比版本 2.x 更新的 gitApple git 这对我有用:

git remote prune origin

For git and Apple git newer than version 2.x this worked for me:

git remote prune origin
过度放纵 2024-11-09 12:45:28

如果 git fetch -p origin 因某种原因不起作用(例如,由于原始存储库不再存在或您无法访问它),另一种解决方案是删除本地存储的信息通过从存储库的根目录进行分支:

rm .git/refs/remotes/origin/DELETED_BRANCH

或者如果它存储在文件 .git/packed-refs 中,则删除相应的行,如下所示

7a9930974b02a3b31cb2ebd17df6667514962685 refs/remotes/origin/DELETED_BRANCH

If git fetch -p origin does not work for some reason (like because the origin repo no longer exists or you are unable to reach it), another solution is to remove the information which is stored locally on that branch by doing from the root of the repo:

rm .git/refs/remotes/origin/DELETED_BRANCH

or if it is stored in the file .git/packed-refs by deleting the corresponding line which is like

7a9930974b02a3b31cb2ebd17df6667514962685 refs/remotes/origin/DELETED_BRANCH
故事未完 2024-11-09 12:45:28

中的配置值

这现在是 .gitconfig [fetch]
prune = true

https://git-scm.com /docs/git-config#Documentation/git-config.txt-fetchprune

This is now a configuration value in .gitconfig

[fetch]
prune = true

https://git-scm.com/docs/git-config#Documentation/git-config.txt-fetchprune

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文