我是否理解正确，Git head（小写）和GIT HEAD（大写）之间的区别在于前者是结束提交，后者只是当前提交（是否选择结束提交或非结束提交作为HEAD提交）？
编辑：通过“end-commit”我的意思是“最后提交一个给定的分支”。
答案 0 :(得分：5)
在git的命令行中，您写道：
HEAD是当前提交，即当前在工作区中结帐的提交。
head的分支或标记，否则 head对GIT没有任何意义。但这听起来不错。
但是当文档谈到分支的 head 时，它引用了该分支的最后一次提交，也许这就是你对 end commit 的意思。在实际命令中，您将使用分支的名称，例如master（或远程头部为origin/master），而不是文字head。
答案 1 :(得分：1)
根据我的检查，＆＃39; head＆＃39;和＆＃39; HEAD＆＃39;两者都可以用来引用当前签出的提交。
您可以签出任何分支提交并使用git show命令检查提交哈希值。
git show head和git show HEAD将显示相同的提交，即当前提交。
答案 2 :(得分：1)
值得一提的是，当您使用不区分大小写的文件系统时（例如Windows和MacOS的默认设置），尝试打开文件abc将会打开现有文件{{ 1}}（如果确实存在），当然反之亦然。
Git将有关当前提交的信息 存储在文件中。在大多数情况下，该文件名为ABC。因此，当Git尝试访问有关当前提交的信息时，它仅打开.git/HEAD并读取它。 （该文件通常包含当前分支的名称。例如，如果您在.git/HEAD分支上，则master文件将显示为：.git/HEAD ）
例如，当您在没有附加参数的情况下运行ref: refs/heads/master时，Git会读取git show来确定您在.git/HEAD上，然后读取master或{ {1}}找出.git/packed-refs意味着哪个提交，并显示该提交。 所有这些都是将来可能会更改的实现细节，并且其中的某些 do 在某些情况下会在现代Git中发生更改，因此依赖 但这就是今天的实际情况。
如果您运行.git/refs/heads/master，Git会尝试找到master，如果行不通，则会尝试找到git show xyz，以查看其中是否有关于分支{{ 1}}。 Git还尝试找到.git/refs/heads/xyz和.git/packed-refs。 Git尝试执行每个操作的确切顺序是另一个实现细节，但实际上是按照某种方式记录下来的；文档在the gitrevisions manual中描述了结果而不是方法。
如果运行xyz，并且在Windows或MacOS上，Git最终将尝试打开.git/refs/tags/xyz。由于您的操作系统愿意将其.git/xyz视为打开请求，并且由于实际上存在git show head ，因此您的操作系统将打开.git/head。 Git从该文件中读取.git/HEAD（或其他任何内容），并向您显示与运行.git/HEAD或仅运行.git/HEAD相同的提交。
在现代的Git中，出现问题的地方是当您处于添加了 的工作树中时，该工作树是通过运行ref: refs/heads/master构建的。在git show HEAD中，添加了 的工作树的git show是 not 。它在git worktree add ...的另一个子目录中。如果您在此添加的工作树中运行HEAD，则Git本身会在全大写字母中看到特殊名称.git/HEAD，并且知道要查找 right {{1} }，用于 this 工作树。但是，如果您运行.git，则Git 不会看到全大写字母git show HEAD，然后继续尝试从HEAD开始打开各种文件。如果此成功-如果打开HEAD-Git将读取 main 工作树的分支，而不是您正在工作的树的分支实际上在添加的工作树中。因此，git show head在添加的工作树中显示了当前的提交；但是HEAD在同一添加的工作树中，显示的是主工作树的当前提交，而不是该提交。
在Linux上，使用通常的文件系统（区分大小写），.git/head根本不起作用。避免这种不良习惯：如果您不喜欢全部用大写字母.git/HEAD，请使用git show HEAD。