所以我是 Windows 10 用户，我在很多分支机构工作。每次我需要在分支中进行推送时，我都会使用 git push origin head。
2 天前，我决定尝试一下 ubuntu，我很享受使用它。唯一的问题是 git push origin head 不再工作了，每次我想推送到一个分支时，我都必须使用 git push origin 和那个分支名称。
这是有原因的吗？这不是世界末日，但我真的很怀念使用 head 而不是输入分支名称
【问题讨论】：
head还是用大写写HEAD？
标签： git ubuntu ubuntu-18.04
始终将HEAD 全部大写。 Git 会特别对待这个特定的名称。它不特别对待小写的head。
使用小写有时适用于某些机器。特别是，它通常适用于 Windows 和 MacOS ...有时。但是，如果您使用 git worktree add 并在添加的工作树中工作，它也会停止在 Windows 和 MacOS 上工作。
如果您不喜欢长时间按住 shift 键，请考虑使用 @ 拼写作为魔术名称。
head（小写）有时但并非总是如此Git 当前将 HEAD 信息（当前分支的名称）存储在一个名为 .git/HEAD 的文件中，除了在添加的工作树中，它将（每个添加的工作树）HEAD 信息存储在子文件中的文件中-.git 的文件夹。
当你像这样在所有大写字母中写 HEAD 时，Git 知道在适当的文件中查找 HEAD 信息——无论是 .git/HEAD 或 .git/worktrees/.../HEAD 还是任何可能的文件。所以它会直接找到正确的信息。
但是，当您将head 写成小写时，Git 会尝试将其用作标记名称 (refs/tags/head)、分支名称 (refs/heads/head) 或远程跟踪名称，例如refs/remotes/origin/head。这个测试有点区分大小写，因为 Git 将分支、标记和远程跟踪名称存储在两个地方：
.git/packed-refs 的纯文本文件中，和/或.git/refs/ 下，例如，.git/refs/tags/head 将保存与名为head 的标签关联的哈希 ID。.git/packed-refs 中的查找是由 Git 自己直接完成的，并且区分大小写。 .git/refs/ 中的查找由操作系统完成。操作系统的查找可能不区分大小写，具体取决于所使用的操作系统和文件系统。
当然，您可能没有名为head 的标签或分支。你的遥控器可能有一个名为HEAD 的符号引用，但在Git 找到它们之前，Git 也 会尝试查看.git 中的普通纯文本文件以查看是否有任何那些 被命名为head。该测试由操作系统再次完成。
如果您的操作系统和文件系统组合区分大小写，则打开和读取名为 head 的文件的请求会打开并读取显然完全不相关的 ? 文件名为 @987654347 @，嗯，那么，你就得到了引用这个.git/HEAD文件的效果。因此，如果您在主工作树中，其 HEAD 信息在 .git/HEAD 中，则全小写名称 head 最终会使用它。
这在 Linux 上失败，普通文件系统知道文件 head 和文件 HEAD 是两个不同的文件，就像“波兰鞋油”不是多余的一样。但它也无法在 Windows 和 MacOS 上添加工作树，因为当您拼写名称 HEAD 时，Git 只会查找每个工作树的 HEAD 信息。如果你使用head（小写），Git 让操作系统读取.git/head，它会为你获取 main 工作树的分支信息，而不是你的 current 工作树。
【讨论】：