警告:refname HEAD不明确(不是其他问题的重复) [英] Warning: refname HEAD is ambiguous (not a duplication of other problems)

问题描述

在将其标记为重复项之前，让我告诉您，我的案例与此处看到的案例之间存在关键差异.

Before you tag this as a duplication, let me tell you that there are key differences between my case and the cases I've seen here.

我正在使用Windows 10设置一个GitLab存储库，并具有一个Unity项目.

I'm setting up a GitLab repo, using Windows 10, have a Unity project.

在命令行中，当我键入 git status 时，我收到警告，但它告诉我我在master分支上.但是，当我键入 git show-ref 时，并没有像其他情况所抱怨的那样得到两个HEAD分支，而是一个HEAD分支和一个master分支.

In the command line, when I type git status I get that Warning but it tells me I'm on the master branch. However, when I type git show-ref I do NOT get two HEAD branches like the other cases have complained about, but rather a HEAD branch and a master branch.

我尚未提交任何东西并将其推送到我的GitLab存储库中.我需要为此担心吗?我知道HEAD分支只是最新的分支.

I haven't yet committed and pushed anything to my GitLab repo. Do I need to worry about this? I understand the HEAD branch is just the most current branch.

推荐答案

...当我键入 git show-ref 时，我没有像其他情况所抱怨的那样得到两个HEAD分支，而是一个HEAD分支和一个master分支.

... when I type git show-ref I do NOT get two HEAD branches like the other cases have complained about, but rather a HEAD branch and a master branch.

我不太确定其他案件所抱怨的"是什么意思，但是问题是您有一个名为 HEAD 的分支.

I'm not quite sure what you mean by "the other cases have complained about", but the fact that you have a branch named HEAD is the problem.

我无法引用图片，但是我可以重新输入在图片中看到的内容:

I can't quote the image, but I can retype what I see in it:

C:\Users\json\AmaraGame>git show-ref
6f35728e7376b71d74187287c985044b665fccab refs/heads/HEAD
e9d8d0c18d59c53ad729e3bf4f935333f898c161 refs/heads/master

，而 refs/heads/HEAD 就是问题所在.那是名为 HEAD 的分支.名称 HEAD 像这样大写， ¹ 很特殊: ² 表示当前分支和它完全生活在一个空间中.分支名称位于名称空间中，其中所有内容均以 refs/heads/开头.标记名称全部在内部以 refs/tags/开头:这就是Git使其保持直线的方式.绝对不能有 refs/heads/HEAD 或 refs/tags/HEAD .如果您有一个名为 master ， ³ 的分支，则不应创建一个名为 master 的标签.由于Git将它们放在单独的空间中- refs/heads/master 与 refs/tags/master - Git 不会将它们混淆，但是 you 可能. ⁴ Git喜欢通过省略 refs/heads/ 和来缩写全名> refs/tags/，这样就剩下 master 和 master .

and that refs/heads/HEAD is the problem. That is a branch named HEAD. The name HEAD, spelled in all uppercase like this,¹ is special:² it means the current branch and it lives in a space all its own. Branch names live in the namespace in which everything starts with refs/heads/. Tag names all start with refs/tags/ internally: that's how Git keeps them straight. There should never be a refs/heads/HEAD nor a refs/tags/HEAD. If you have a branch named master,³ you should not create a tag named master. Since Git keeps them in separate spaces—refs/heads/master vs refs/tags/master—Git will not mix them up, but you might.⁴ Git likes to abbreviate the full names by leaving off refs/heads/ and leaving off refs/tags/, and this leaves you with master and master.

在任何情况下，由于 HEAD 在其自己的空间中，根本没有前缀 refs/，因此Git不会混淆它们，但是您可以.您应该将名为 HEAD 的分支重命名为其他名称，如警告中所示:refname'HEAD'不明确.

In any case, since HEAD is in its own space, not prefixed with refs/ at all, Git won't mix them up, but you might. You should rename the branch named HEAD to some other name, as shown in warning: refname 'HEAD' is ambiguous.

请注意，Git会自行创建 refs/remotes/origin/HEAD 之类的名称.这是一个远程跟踪名称. ⁵ 这些不会引起胃灼热，因为Git通过删除 refs/来缩写这些名称(在 git branch -a 输出中)或 refs/remotes/(在大多数其他输出中).剩下 origin/HEAD 作为缩写名称，这与特殊名称 HEAD 区别开来.

Note that Git will, on its own, create names like refs/remotes/origin/HEAD. This one is a remote-tracking name.⁵ These don't cause any heartburn because Git abbreviates these names by removing either just refs/ (in git branch -a output) or refs/remotes/ (in most other output). That leaves origin/HEAD as the abbreviated name, which distinguishes it from the special name HEAD.

¹ 在Windows和MacOS上，您通常可以使用小写的 head 代替大写的 HEAD .这通常在Linux上不起作用.出于多种原因，我在这里通常说 和 .

¹On Windows and MacOS, you can often use lowercase head instead of all-caps HEAD. This generally doesn't work on Linux. I say often and generally here for multiple reasons.

首先，它是否起作用以及何时起作用不由Git本身控制，而是由您的OS及其底层文件系统控制，并且可以告知Windows和MacOS 使用区分大小写的文件系统，可以告诉Linux和 使用不区分大小写的文件系统.但是默认设置是Windows或MacOS文件系统不区分大小写，而Linux文件系统则区分大小写.

First, whether and when this works is controlled not by Git itself, but rather by your OS and its underlying file systems, and Windows and MacOS can be told to use case-sensitive file systems, and Linux can be told to use a case-insensitive file system. But the defaults are that your Windows or MacOS file system is case-insensitive, and your Linux file system is case-sensitive.

第二，如果您有一个在其中运行 head 的系统，并使用 git worktree add ，您会发现大写的 HEAD 可以运行 right 在添加的工作树中，而小写的 head 却错误地显示 :添加了工作树.这是由于Git解析名称时使用的规则.大写的特殊名称 HEAD (Git本身区分大小写)被转换为适当的每工作树文件名.小写的名称 head 与大写的 HEAD 不匹配，因此Git继续进行

Second, if you have a system in which head works, and use git worktree add, you will find that uppercase HEAD works right in an added work-tree, and lowercase head works wrong: it gets you the wrong branch name in that added work-tree. This is because of the rules Git uses when resolving names. The special name HEAD, in all capitals—Git itself is case-sensitive—is turned into the appropriate per-work-tree file name. The name head, in all lowercase, doesn't match HEAD in all uppercase, so Git goes on to the six-step process outlined in the gitrevisions documentation. See also footnote 4.

如果您不希望在输入所有四个字母时按住Shift键，请考虑使用 @ 同义词.您可以输入 @ 来代替 HEAD .例如， git rev-parse HEAD 和 git rev-parse @ 打印相同的哈希ID.

If you don't like holding down the shift key while typing all four letters, consider using the @ synonym. Instead of HEAD you can just type in @. For instance, git rev-parse HEAD and git rev-parse @ print the same hash ID.

² 有类似的特殊名称，它们以 _HEAD 结尾.它们比 HEAD 本身没什么特别的"，但是它们在内部仍然不是以 refs/开头的，Git的各个部分以各种方式使用它们.这些内容在 gitrevisions文档的六步式解决方案的第1步中列出符号名称过程；参见脚注4.

²There are similar special names that end in _HEAD. They are "less special" than HEAD itself but they still don't start with refs/ internally, and various parts of Git use them in various ways. These are listed in the gitrevisions documenation in step 1 of its six-step resolve a symbolic name process; see footnote 4.

³ 具有一个名为 master 的分支实际上是可选的.该名称仅对Git有点特殊.但是，省略分支名称 master 和使用该名称作为标记名称可能仍然是不明智的.

³Having a branch named master is in fact optional. The name is only slightly special to Git. It's probably still unwise to both omit the branch name master and use the name as a tag name, though.

⁴ gitrevisions文档描述了一个六步过程解析符号名称，例如 master 或 heads/master .步骤1涉及检查存在于 $ GIT_DIR 中的各种特殊 * _ HEAD 名称.这就是Windows和MacOS上容易出错的地方:因为OS进行大小写折叠名称比较，所以名称 head 与 $中名为 HEAD 的文件匹配.GIT_DIR .对于主要的工作树，这是正确的文件，对于添加的工作树，这是错误的文件.因此，作为一般规则，请勿将您的任何分支命名为 head ，但不要使用 fetch_head ， orig_head ，merge_head 或 cherry_pick_head .实际上，最好不要使用 * _ head 形式的任何东西.

⁴The gitrevisions documentation describes a six step process for resolving a symbolic name like master or heads/master. Step 1 involves checking for the various special *_HEAD names that live in $GIT_DIR. This is where things tend to go wrong on Windows and MacOS: because the OS does case-folding name comparisons, the name head matches the file named HEAD in $GIT_DIR. This is the right file for the primary work-tree, and the wrong one for added work-trees. So, as a general rule, don't name any of your branches head—but don't use fetch_head, orig_head, merge_head, or cherry_pick_head either. In fact, it's probably best to stay away from anything of the form *_head.

第2步是尝试在前面添加 refs/.这样，您就可以编写 heads/master 或 tags/master 来选择是 branch 名称还是 tag 名称，如果您正在解决意外的歧义.当然，您可以只编写 refs/heads/master 或 refs/tags/master ，甚至不必进入步骤2:当您的名字以 refs开头时/，Git已经知道使用下一个单词来选择名称空间.

Step 2 is to try adding refs/ in front. This lets you write heads/master or tags/master to pick whether you want the branch name or the tag name, if you're in the process of fixing an accidental ambiguity. Of course you can just write refs/heads/master or refs/tags/master and not even have to get to step 2: when your name starts with refs/, Git already knows to use the next word to pick the name-space.

第3步尝试在前面添加 refs/tags/，第4步尝试在前面添加 refs/heads/，第5步和第6步用于远程跟踪名称.请注意，在模棱两可的情况下，此过程更喜欢 tag 名称而不是 branch 名称.这意味着 master 将引用 tag 而不是 branch ...，例如，对于 git show master.但是，如果您运行 git checkout master ，则 git checkout 命令将首选 branch 名称！因此，分支之前的标签"规则的应用有些不一致.Git有明确定义的规则，但是试图将它们全部保留在自己的头顶上，放在脖子上，是，让我们说这不是一个好计划.

Step 3 is to try adding refs/tags/ in front, step 4 is to try adding refs/heads/ in front, and steps 5 and 6 are for remote-tracking names. Note that this process prefers tag names to branch names in ambiguous cases. That implies that master will refer to the tag rather than the branch ... and that's true for, e.g., git show master. But if you run git checkout master, the git checkout command will prefer the branch name! So the "tags before branches" rule is applied somewhat inconsistently. Git has well-defined rules, but trying to keep them all in your own personal head, perched atop your neck, is, well, let's just say not a good plan.

⁵ Git调用这些 refs/remotes/origin/命名空间名称​​远程跟踪分支名称.它们不是分支名称！分支名称是 refs/heads/中的名称.您的Git会根据其他Git的分支名称(如在 origin 之类的 remote 上看到的)来创建您的远程跟踪名称.从某种意义上说，它们从远程"中跟踪"分支名称.但是，短语远程跟踪分支名称鼓励您将其视为分支名称，但事实并非如此.另外，可怜的 branch 这个词在Git中已经工作过度.让我们将其省略，而使用短语远程跟踪名称.

⁵Git calls these refs/remotes/origin/ name-space names remote-tracking branch names. They are not branch names! Branch names are the ones in refs/heads/. Your Git creates your remote-tracking names based on some other Git's branch names as seen on a remote like origin. In some sense, they "track" branch names from a "remote". But the phrase remote-tracking branch names encourages you to think of them as branch names, and they aren't. Plus, the poor word branch is already overworked in Git. Let's just leave it out and use the phrase remote-tracking name instead.

这篇关于警告:refname HEAD不明确(不是其他问题的重复)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！