Git - head(小写)与 HEAD(大写)

Question

我是否理解正确，Git head(小写)和 Git HEAD(大写)的区别在于前者是结束提交，后者只是当前提交(无论是最终提交还是非最终提交被选为 HEAD 提交)？

编辑:“结束提交”是指“给定分支的最后一次提交”。

Answer 1

值得一提的是，当您使用不区分大小写的文件系统时(例如 Windows 和 MacOS 上的默认设置)，尝试打开文件 abc 将打开现有文件文件 ABC，如果它确实存在，当然反之亦然。

Git 在文件中存储关于当前提交的信息。在大多数情况下，该文件名为 .git/HEAD。因此，当 Git 尝试访问有关当前提交的信息时，它只是打开 .git/HEAD 并读取它。 (该文件通常包含 当前分支的名称。例如，如果您在 master 分支上，您的 .git/HEAD文件将显示为:ref: refs/heads/master。)

例如，当您运行 git show 时没有附加参数，Git 会读取 .git/HEAD 以发现您在 master，然后读取 .git/packed-refs 或 .git/refs/heads/master 以找出 master 意味着哪个提交，并显示该提交。 所有这些都是 future 可能会改变的实现细节，其中一些确实在某些情况下在现代 Git 中会发生变化，因此依赖是不明智的 但这就是今天的实际运作方式。

如果您运行 git show xyz，Git 会尝试查找 .git/refs/heads/xyz，如果这不起作用，则会尝试查找 .git/packed-refs 查看是否有关于分支 xyz 的行。 Git 还尝试查找 .git/refs/tags/xyz 和 .git/xyz。 Git 尝试这些操作中的每一个的精确顺序是另一个实现细节，但实际上是记录在案的——以某种方式；文档描述的是结果，而不是方法——在 the gitrevisions manual 中.

如果您运行 git show head，并且您使用的是 Windows 或 MacOS，Git 最终会尝试打开 .git/head。由于您的操作系统愿意将其视为打开请求，而不是 .git/HEAD，并且由于 .git/HEAD 确实如此实际上存在，你的操作系统打开 .git/HEAD。 Git 从该文件中读取 ref: refs/heads/master (或其他)，并向您显示如果您运行 git show HEAD 或只是普通的 git show。

在现代 Git 中，当您在 added 工作树中时，出错的地方是通过运行 git worktree add ... 构建的工作树。 添加 工作树的HEAD 不在.git/HEAD 中。它位于 .git 的另一个子目录中。如果你在这个添加的工作树中运行 git show HEAD，Git 本身会看到特殊名称 HEAD 并且知道查找 正确的 HEAD，这个 工作树。但是如果你运行 git show head，Git 不会看到全大写的 HEAD，并继续尝试打开各种文件，从 .git/head 开始。如果这成功——如果它打开.git/HEAD——Git 读取main 工作树的分支，而不是您实际上在添加的工作树中的工作树。所以 git show HEAD，在添加的工作树中，显示那里的当前提交；但是 git show head，在同一个添加的工作树中，显示了主工作树的当前提交，而不是这个。

在 Linux 上，使用通常的文件系统(区分大小写)，git show head 根本不起作用。避免这个坏习惯:如果您不喜欢全大写输入 HEAD，请使用 @。