警告重命名git遥控器
尝试重命名git遥控器时，我会收到以下警告：
> git remote rename origin old-origin
warning: Not updating non-default fetch refspec
+refs/*:refs/*
Please update the configuration manually if necessary.
我找到了一个如此发帖（我如何重命名git遥控器？）谈论这个问题，这应该有效。它 会重命名遥控器，但是为什么要警告呢？警告是什么意思，应该解决的问题是什么？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
tl; dr
您有一个镜面克隆。确定您想对此做什么。
长期
警告恰恰意味着它说的话。诀窍是了解A fetch refspec 通常是什么，而这个特定的特定是什么。让我们从参考和refspecs开始，然后才能深入研究 fetch refspecs。
refs and Refspecs
a ref 在git中是一个名称。它或多或少那么简单：这是包含分支名称的通用单词，例如
main或master，标签名称，例如v1.2，远程 - 跟踪名称Origin/develop，依此类推。裁判有很多，它们都有“全名”版本。为了方便起见，大多数人都有一个“缩写”版本，例如詹姆斯·提比略·柯克（James Tiberius Kirk）和“哈里·穆德（Harry Mudd）”的简短，对于“ Harcourt Fenton Mudd”而言。所有分支实际上都与
refs/head/一起使用，因此main是refs/heads/main的简短。所有 tag 的名称实际上都与refs/tags/一起，因此v1.2是refs/tags/v1.2 < /代码>。远程跟踪名称以refs/promotes/开头，然后继续包含遥控器的名称，例如origin，然后是 branch的简短形式名称如该遥控器上所示。因此，如果某些其他 git存储库具有分支开发，并且您将该存储库“知道”为onement，您通常会选择拥有git”请记住，“他们的分支开发- 您refs/heads/develop- 作为您的refs/ymotes/infortes/oneques/onect/develop。每个参考文献（eram）名称 - 存储一个哈希ID。有些裁判可以存储任何类型的哈希ID，并且某些（尤其是分支名称）受到更大的约束，并且必须持有A commit hash ID（git在内部具有四种类型的哈希ID）。我们不需要在这里担心这些区别，但是如果您建立不良的refspec，您可以（至少尝试）违反约束，因此值得一提。不过，更重要的是，在名称中存储哈希ID的要点是让我们人类使用使用 请参阅特定的consits 。这样，即使Git要求我们为GIT提供原始的哈希ID，我们也可以找到 而不必自己记住哈希ID的承诺。我们可以将 name 提供给git，git将使用我们提供的名称来查找原始哈希ID，然后使用原始哈希ID来查找提交。
换句话说，该名称允许我们向git 间接提供原始哈希ID 。我们只能呼吁“提交标记为v1.2”或“最新<代码>开发 -branch commit”并获取正确的。在重要意义上，git本身根本不需要这些名称（尽管它会大量使用它们，以促进使人类变得容易，这包括“垃圾收集“否则”否则“死”的想法提交，其中“死”的意思是“无法使用名称找到”）。
A refspec 以其第二幅度形式，只需一对由结肠隔开的refs。最简单的形式是一个单个名称，但是在我们这里的上下文中，此类refspecs并不是很明智 - 它们主要对
git push> - 因此，我们现在完全忽略了它们。当我们编写RefSpec时，尤其是对于
git fetch，我们将 source 名称放在colon的左侧：：字符和a 目标右侧名称。例如，refspec：表示我们想要的 source 是 branch name
开发和 destination 我们想要的是远程跟踪名称ORIGIAN/DEVELED。任何RefSpec都可以用加号
+前缀，以设置 force flag 。我们稍后再回到这个。提取和推送refspecs也可以以有限的方式与类似shell-glob的*字符交易：是一个refspec，说 source 是“每个分支名称“，因为
*匹配main，开发，功能/高等等。 1 < /sup> destination 从左侧拿起匹配的字符串，并在refs/promeotes/onect/之后插入它，因此，这成为远程跟踪名称，其远程为oincor 。他们的main成为我们的Origin/main;他们的功能/短成为我们的origin/feation/tall。简而言之，这是我们使用Fetch Refspecs的通常方式：它们导致我们其他一些GIT存储库中的Git克隆具有其每个分支名称的远程跟踪名称。但是，我们通常还设定力标志。
1 这种
*可以在/中匹配的事实使其与Shell Glob不同。有力标志
可以在任何时间使用
git Update-ref例如以创建或销毁或更新任何参考文献时，可以或多或少地告知， 或多或少。该命令属于Git调用 plumbing 的一组命令，与git称为瓷器的组形成鲜明对比。在某种意义上是使用plumbing命令作为使某些有趣的事情成为较大程序的一部分的基础。瓷器命令是为了让人类互动。瓷器命令倾向于检查人为错误，并确认是否看起来像 hinky 。因此，我们（人类）通常会运行git分支或git tag以创建一个新的分支或标签，例如，而不是运行git git Update-ref ref </代码>;但是，更新-REF通常会按照我们的要求完全更新任何 REF，即使这是否是显而易见的错误，也没有问题。当我们特别使用分支名称时，我们正在创建 new 提交时，我们甚至不必调用
git branch，更少的git Update-ref。我们只是简单地查看 一些分支名称（或git switch，因为git 2.23引入了较小的错误git switch命令）和然后进行工作并运行git commit。git commit命令：此将上的提交添加到分支：之前存在的提交， 2 ，现在在分支上还有一个提交，即我刚刚做出的一个提交。这就是分支机构一次有机地生长的方式。
我们还可以将添加多个提交在分支名称中，在git称为快速前进的操作中，有时是 快速向前的合并。 3 就git具有任何想法或感觉， 4 git“ likes” 添加对分支的承诺，从而移动一个分支名称 “向前”。无论是一次通过
git commit，还是通过“快速前向”一次性提交，Git很乐意 add 提交。因此，如果我们运行
git提取并获得一些新的从某些其他git存储库中提交的 - 无论如何 - 还是向我们发送 - 和他们的一个分支名称已“向前迈进”以包含这些新提交，我们的git软件将很乐意移动我们的分支名称或远程跟踪名称也可以向前移动！但是，我们可以使用git reset例如，我们可以 force git放弃提交。 git是“不愿”这样做的，如果我们运行git fetch并发现另一个git存储库已缩回 a分支，请弹出一些末端，我们自己Git对此会不满意。我们可能不得不 force 。考虑到这一点，让我们更仔细地看一下git fet本身。2 >除非，也就是说，我使用
git commit -amend，在这种情况下，该提交仍然存在，但是 不再“在”分支上因为在新提交的元数据中存储的 parent 哈希ID并不是我已签出的提交的哈希ID。3 名称 fast-forward 可能来自盒式磁带和较早的录制技术。我们仍然具有数字视频的概念：您的DVR和/或Bluray播放器可能具有快速曲线的按钮。一词快速合并是有点毫无意义的：根本没有实际的合并发生。那只是一个“ git”：您只需要记住，在
git Merge的上下文中，A 快速前进没有进行任何实际合并。也许这取决于您如何定义合并，但是我定义它的方式，没有涉及合并。4 不要拟人化计算机。他们讨厌那个！ （属于Andrew McCafee 。我不确定我第一次听到哪里，可能是旧的BSD“ Fortunes”数据库。）
git如何Fetch我前面提到的作品，git不需要需要分支和标签名称，或更一般的“ refs”来查找提交。那是因为每个提交都有一个唯一哈希ID。如果我们要记住我们所有的git commit hash ids，我们可以直接将它们交给git。而且，每当任何人添加任何对 任何 git存储库时， new commit都会获得一个新的，独特的哈希ID：从未使用过的一个以前，在任何地方的任何git存储库中，在任何其他git存储库中都无法再使用，除非要用于 。 5
反过来，这意味着与任意两个存储库一起工作的任何两个GIT实现都可以简单地交换RAW HASH ID ，以查看一个人是否具有与另一个相同的承诺。这个想法是
git fet的核心：我们将 连接到了我们的存储库的 git软件，与其他一些git存储库的其他git软件联系在一起。让我们分别称这些为“我们的git”和“他们的git”。现在，我们将他们的git列表列出了他们的一些或全部提交哈希ID。当他们列出我们不认识的哈希ID时，这意味着他们有我们缺乏的承诺。我们可以选择要求他们向 send 我们提交（其元数据和快照，最好是以压缩形式）。 6 git使用其向后看的提交图形来执行此操作有效。它通常还使用 name 来开始过程。 7 这正是refspecs进来的位置。
形式的refspec：
告诉我们的git git将其git列表淘汰出来他们所有的分支名称和相应的提交哈希ID。然后，我们让我们的git询问他们在我们在存储库中根本没有的分支机构上拥有的每一个承诺。
在此过程结束时，我们的git软件知道他们所有的分支名称和哈希ID。现在，我们可以将您的软件保存此信息
存储库。为此，我们只需要告诉它：对于他们拥有的每个分支名称，创建或更新相应的远程跟踪名称。
这是RefSpec的一个示例，这就是fetch RefSpec曾经是并且确实如此。它从其 存储库中获取一些名称（s），并在我们的存储库中创建和/或更新相应的名称。
每当这些名称是某些名称时（例如，分支或标签名称），我们的git可能不愿意进行“可疑的”更新，例如滚动一个分支名称“向后”。对于我们的软件，我们只需将力标志添加到RefSpec中即可。因此：：
告诉我们的git软件在我们的存储库中使用其所有 branch 名称，并在我们的存储库中创建或更新远程跟踪名称，即使需要“强制更新”才能弹出consits在我们的远程跟踪名称之一的末尾。
这个特殊的refspec是 bog-standard
git fetch fetchrefspec refspec对于遥控器Origin。实际上，无论遥控器的名称是什么，+refs/heads/：refs/promotes/远程/是预期的默认repspec，这将导致他们所有的分支都将成为我们所有远程跟踪名称。 8，因为这是标准的，
git remote Rename知道如何将其更改到位。不仅Willgit Remote Rename替换标准fetch =refspec设置，它还将重命名所有本来可以创建的 的远程跟踪名称环境。也就是说：将替换
为：
它还将重命名所有现有
onement/*远程跟踪名称为xyzzy/*名称。5 新发现的SHA-1碰撞如何影响Git？ /a>
6 许多精美的图形理论都进入了这种压缩，并且效果很好，除非您正在使用浅存储库。它在浅层存储库中的工作效果或效果不佳，对此可以做什么，至少是一两篇论文的话题。
7 由于分支名称，根据定义，最新 commit，这似乎是理想的。吉特（Git）已经有了它为我们人类保留的名字 - 裁判。为什么不使用它们来提高git呢？请注意，在过去，GIT在此处有一些可选的限制防止 在这里使用原始哈希ID，但是新范围的“承诺遥控器”功能或多或少地将这个特定的婴儿扔给了沐浴间。
8 作为一种缺陷，此无法删除它们曾经拥有的任何分支名称，我们将其转换为远程跟踪名称并因此在存储库中创建。也就是说，他们 at a
refs/heads/foo，因此我们创建了refs/ymotes/equotes/onect/foo。然后，他们删除他们的foo分支，所以我们...只需停止更新我们现有的refs/refs/remotes/onectes/onect/foo 。这是一个剩下的；它已经过时了。要摆脱它，我们必须让我们的git软件询问其所有分支名称，请注意，他们 没有foo更多， delete 我们的onect/foo名称。 git调用此 pruning 远程，您可以使用git远程修剪或git fetch -prune使其实现。您甚至可以将Git的配置变量设置为
fetch.prunetrue制作git fetth默认情况下。事实证明，周围有一些（次要的）锋利的边缘，因此，如果您设置此设置，知道自己在做什么是明智的。就我个人而言，我认为Git应该始终做到这一点，并在很久以前就弄平了粗糙的边缘，但是Git就是它。您的获取refspec是a rigral refspec
上述所有内容都在谈论普通日常 fetch refspec，但是您的克隆人有：
因为所有refs均以
refs/，此refspec说，每当您运行git fetch到此遥控器时，您的git软件都应采用 每个参考在您的存储库中参考。也就是说，如果他们有分支
main和开发和feature/tall，您将完全擦除现有的分支名称MAIN和开发和功能/高和用他们的分支名称哈希IDS 替换它们。 （请参阅有关修剪的脚注8：一面镜子通常还应该修剪以避免累积陈旧的名称，但我不知道您是否会累积。 。其中包括
refs/替换/*由git替换制作的名称。如果有的话，它包括他们的远程跟踪名称。您可以通过运行
git克隆来获得这种克隆 - mirror，它设置了一个裸露的镜子克隆，没有人会做任何工作。这种克隆的目的是充当本地缓存。例如，这种事情在一些较大的公司中很常见：SF总部中有一个“真实的来源”（SSOT）GIT存储库，但是数据线将用于Peoria或Auckland，或任何地方，或者在任何地方都很慢，很昂贵，很昂贵，因此，您没有直接在卫星办公室里有十几个左右的员工，您可以在卫星办公室设置一个 Mirror ，并经常更新（例如，每10或15分钟）并让那里的员工克隆本地克隆。 每个克隆而不是小时。这需要几秒钟的 在这里提出任何扎实的建议。
9 这里也有其他有用的技巧。例如，我从一个地方使用参考克隆将克隆时间从大约一个小时减少到大约30秒。
TL;DR
You have a mirror clone. Decide what you want to do about this.
Long
The warning means exactly what it says. The trick is to understand what a fetch refspec is in general and what this particular one is specifically. Let's start with refs and refspecs before we dive into fetch refspecs.
Refs and refspecs
A ref, in Git, is a name. It's more or less that simple: it's the generic word that encompasses branch names like
mainormaster, tag names likev1.2, remote-tracking names likeorigin/develop, and so on. There are many kinds of refs and they all have a "full name" version; most have a "short name" version for convenience, like "Kirk" is short for James Tiberius Kirk and "Harry Mudd" is short for "Harcourt Fenton Mudd".All branch names actually being with
refs/heads/, somainis short forrefs/heads/main. All tag names actually being withrefs/tags/, sov1.2is short forrefs/tags/v1.2. Remote-tracking names begin withrefs/remotes/and go on to include the name of the remote, such asorigin, and then the short form of the branch name as seen on that remote. So if some other Git repository has branchdevelop, and you "know" that repository asorigin, you would typically choose to have your Git "remember" their branchdevelop—theirrefs/heads/develop—as yourrefs/remotes/origin/develop.Each ref—each name—stores one hash ID. Some refs can store any kind of hash ID, and some (branch names in particular) are more constrained and must hold a commit hash ID (Git has four types of hash ID internally). We don't need to worry about these distinctions much here, but if you build a bad refspec, you can (at least attempt to) violate the constraints, so it's worth mentioning in passing. More importantly though, the point of storing a hash ID in a name is to allow us humans to use names to refer to particular commits. This way we can find the commits without having to remember hash IDs ourselves, even though Git requires that we supply the raw hash ID to Git. We can supply the name to Git, and Git will use the name we supplied to find the raw hash ID, and then use the raw hash ID to find the commit.
In other words, the name allows us to supply the raw hash ID to Git indirectly. We can just call for "the commit tagged v1.2" or "the latest
develop-branch commit" and get the right one. Git itself does not, in an important sense, need the names at all (though it makes a whole lot of use of them, in furtherance of making things easy for humans, and this includes the idea of "garbage collecting" otherwise "dead" commits, where "dead" means "cannot be found using a name").A refspec is, in its second-simplest form, simply a pair of refs separated by a colon. The simplest form is a single name, but such refspecs are not very sensible in our context here—they're mainly useful with
git push—so we'll ignore them entirely for now.When we write a refspec, especially for
git fetch, we put a source name on the left side of the colon:character and a destination name on the right side. For instance, the refspec:means that the source we'd like is the branch name
developand the destination we'd like is the remote-tracking nameorigin/develop.Any refspec can be prefixed with a plus sign
+, which sets the force flag. We'll come back to this later. Both fetch and push refspecs can also deal, in a limited fashion, with shell-glob-like*characters:is a refspec that says that the source is "every branch name", because
*matchesmain,develop,feature/tall, and so on.1 The destination takes the matched string from the left and inserts it afterrefs/remotes/origin/, so this becomes a remote-tracking name whose remote isorigin. Theirmainbecomes ourorigin/main; theirfeature/shortbecomes ourorigin/feature/tall.This is, in short, the usual way we use fetch refspecs: they cause our Git clone of some other Git repository to have remote-tracking names for each of their branch names. However, we also normally set the force flag.
1The fact that this kind of
*can match across/makes it different from a shell glob.The force flag, with a side of plumbing
Git can be told, at more or less any time using
git update-reffor instance, to create, or destroy, or update any ref. This command falls into the group of commands that Git calls plumbing, as contrasted with the group that Git calls porcelain. A plumbing command is meant, in a sense, to be used as a building block to make something interesting happen as part of a larger program. A porcelain command is meant for a human to interact with. Porcelain commands tend to check for human error, and confirm things if something looks hinky. So we (humans) would more typically rungit branchorgit tagto create a new branch or tag, for instance, rather than runninggit update-ref; but update-ref will generally updated any ref exactly as we tell it, no questions asked, even if that's an obvious blunder.When we work with branch names in particular, and we're creating new commits, we don't even have to invoke
git branchat all, much lessgit update-ref. We simply check out some branch name (orgit switchto it, since Git 2.23 introduced the less-error-pronegit switchcommand) and then do work and rungit commit. Thegit commitcommand:This adds a commit on to the branch: the commit that was there before is still there,2 and now there's one more commit on the branch, namely the one I just made. This is how branches grow organically, as it were, one commit at a time.
We can also add more than one commit to a branch name, in an operation that Git refers to as a fast-forward, or sometimes a fast-forward merge.3 Insofar as Git has any thoughts or feelings,4 Git "likes" adding commits to a branch, thus moving a branch name "forward". Whether that's one commit at a time, via
git commit, or a bunch all at once via a "fast-forward", Git is happy to add commits.So, if we run
git fetchand get some new commits from some other Git repository—new to us anyway—and one of their branch names has "moved forward" to encompass these new commits, our Git software will be happy to move our branch names or remote-tracking names forward too! But we can force Git to give up a commit, usinggit resetfor instance. Git is "reluctant" to do that, and if we rungit fetchand find that the other Git repository has retracted a branch, ejecting some commits off the end, our own Git will be unhappy about this. We may have to force this. With that in mind, let's look atgit fetchitself a bit more closely.2Unless, that is, I used
git commit --amend, in which case the commit is still there but isn't "on" the branch any more because the stored parent hash ID in the new commit's metadata is not the hash ID of the commit I had checked out.3The name fast-forward likely comes from cassette tapes and earlier recording technologies. We still have the concept with digital video: your DVR and/or BluRay player likely have a fast-forawrd button. The term fast-forward merge is a bit of technical nonsense: there's no actual merge happening at all. That's just a "Git thing": you just have to remember that in the context of
git merge, a fast-forward isn't doing any actual merging. Perhaps that depends on how you define merge, but the way I define it, there's no merging involved.4Don't anthropomorphize computers. They hate that! (Attributed to Andrew McAfee. I'm not sure where I first heard it, probably the old BSD "fortunes" database.)
How
git fetchworksI mentioned earlier that Git doesn't need branch and tag names, or more generally "refs", to find commits. That's because every commit has a unique hash ID. If we were to memorize all our Git commit hash IDs, we could just give those directly to Git. And, whenever anyone adds any commit to any Git repository, that new commit gets a new, unique hash ID: one that has never been used before, in any Git repository anywhere, and can never be used again, in any other Git repository, unless it is to be used for that very commit.5
This in turn means that any two Git implementations, working with any two repositories, can simply exchange raw hash IDs to see whether one has the same commits as the other. This idea is at the heart of
git fetch: we connect our Git software, looking at our repository, to some other Git software looking at some other Git repository. Let's call these "our Git" and "their Git" respectively.We now have their Git list out some or all of their commit hash IDs. When they list out a hash ID that we don't recognize, that means they have a commit that we lack. We can choose to ask them to send us that commit (its metadata and snapshot, preferably in a compressed form).6 Git uses its backwards-looking commit graph to do this efficiently. It also typically uses names to get the process started.7 This is precisely where the refspecs come in.
A refspec of the form:
tells our Git to have their Git list out all their branch names and the corresponding commit hash IDs. We then have our Git ask their Git for every commit that they have on their branches that we don't have at all in our repository.
At the end of this process, our Git software knows all their branch names and hash IDs. We can now have our software save this information into our
repository. To do that, we just have to tell it: for each branch name they have, create or update the corresponding remote-tracking name.
That's an example of a refspec, and that's what a fetch refspec is and does. It takes some name(s) from their repository and creates and/or updates corresponding names in our repository.
Whenever those names are certain kinds of names—branch or tag names, for instance—our Git may be reluctant to make "suspicious-looking" updates, like rolling a branch name "backwards". To force our software to do that, we simply add the force flag to the refspec. So:
tells our Git software to take all their branch names and create or update remote-tracking names in our repository, even if that requires a "forced update" to eject commits off the end of one of our remote-tracking names.
This particular refspec is the bog-standard
git fetchrefspec for the remote namedorigin. Indeed, whatever the remote's name is,+refs/heads/:refs/remotes/remote/is the expected default refspec, which will cause all their branches to become all our remote-tracking names.8Because this is standard,
git remote renameknows how to change it in place. Not only willgit remote renamereplace the standardfetch =refspec setting, it will also rename all the remote-tracking names that would have been created by that setting. That is:will replace:
with:
it will also rename all existing
origin/*remote-tracking names toxyzzy/*names.5The pigeonhole principle tells us that this cannot work forever, and it won't: someday Git will fail. The sheer size of hash IDs puts that day far into the future (we hope, anyway). The conditions for failure, and the precise way Git will fail, are tricky: see How does the newly found SHA-1 collision affect Git?
6A lot of fancy graph theory goes into this compression, and it works really well, unless you're using shallow repositories. How well or poorly it works for shallow repositories, and what can be done about this, is a topic for at least a paper or two.
7Since a branch name, by definition, names the latest commit, this seems pretty much ideal. Git already has the names—the refs—that it's keeping for us humans; why not use them to make Git efficient for itself too? Note that in the old days, Git had some optional restrictions to prevent use of raw hash IDs here, but the newfangled "promisor remotes" feature have more or less thrown this particular baby out with the bathwater.
8As a sort of defect, this fails to delete any branch names they once had, that we converted to a remote-tracking name and therefore created in our repository. That is, they had a
refs/heads/fooso we created arefs/remotes/origin/foo. Then they deleted theirfoobranch and so we ... simply stop updating our existingrefs/remotes/origin/foo. It's a left-over; it has gone stale. To get rid of it we have to have our Git software ask about all their branch names, notice that they don't have afooany more, and delete ourorigin/fooname. Git calls this pruning a remote and you can usegit remote pruneorgit fetch --pruneto make it happen.You can even set Git's configuration variable
fetch.prunetotrueto makegit fetchdo it by default. It turns out there are some (minor) sharp edges around this, though, so it's wise to know what you're doing, if you set this. Personally, I think Git should always have just done this, and smoothed out the rough edges long ago, but Git is what it is.Your fetch refspec is a mirror refspec
All of the above talks about the normal everyday fetch refspec, but your clone has:
Since all refs start with
refs/, this refspec says that, whenever you rungit fetchto this remote, your Git software should take every ref they give you and create or update the same ref in your repository.That is, if they have branches
mainanddevelopandfeature/tall, you'll completely wipe out your existing branch namesmainanddevelopandfeature/talland replace them with their branch name hash IDs. (See footnote 8 about pruning: a mirror should generally also have pruning turned on to avoid accumulating stale names, but I don't know if yours does.)Instead of remote-tracking names, then, your Git slavishly copies all of their refs. That includes
refs/replace/*names made bygit replace. It includes their remote-tracking names, if they have any.You get this kind of clone by running
git clone --mirror, which sets up a bare mirror clone in which no one will ever do any work. The purpose of such a clone is to act as a local cache. This sort of thing is common in some larger companies, for instance: there's a "single source of truth" (SSoT) Git repository in the SF headquarters, but the data line going to Peoria or Auckland or wherever is kind of slow and expensive, so instead of having a dozen or so employees in the satellite office all clone the SSoT repository directly, you set up one mirror in the satellite office and update it frequently (say, every 10 or 15 minutes) and have the employees there clone the local clone. This takes seconds per clone instead of hours.9It's not typical to rename the remote in a mirror clone, so we'd need to know a lot more about what you're really doing and why, to make any kind of solid recommendation here.
9There are other useful tricks here too. I literally reduced the clone time for a multi-repository build from about an hour to about 30 seconds using reference clones at one place, for instance.
fetch.git/config中的行指定哪些分支是从特定遥控器中获取的，在哪些局部ref路径下它们将被镜像。的示例。
在这里，默认
onectfetch行指示git以从远程获取所有头（refs/heads/*） 并将它们本地存储为Origin/*远程分支。显然，您的
fetch行与默认值不同，并将远程分支反映在带有相同名称的常规本地分支上；而不是远程分支这就是为什么您会得到警告。
您是否要将行更改为默认值取决于您。
The
fetchline in.git/configspecifies which branches are fetched from a particular remote and under which local ref path they will be mirrored.Here an example of the default
originThe
fetchline instructs git to fetch all heads (branches) from the remote (refs/heads/*) and stores them locally asorigin/*remote branches.Apparently your
fetchline differs from the default and mirrors the remote branches onto regular local branches with the same names; instead of remote branchesThat's why you get that warning.
Whether you want to change the line back to its default is up to you.