我是否正确理解 Git head(小写)和 Git HEAD(大写)之间的区别是前者是 最终提交,而后者只是当前提交(无论是选择作为 HEAD 提交的最终提交还是非最终提交)?
编辑:我所说的“最终提交”指的是给定分支的“最后一次提交”。
我是否正确理解 Git head(小写)和 Git HEAD(大写)之间的区别是前者是 最终提交,而后者只是当前提交(无论是选择作为 HEAD 提交的最终提交还是非最终提交)?
编辑:我所说的“最终提交”指的是给定分支的“最后一次提交”。
abc
会打开现有的文件ABC
,如果存在的话,反之亦然。.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
表示哪个提交,并显示该提交。所有这些都是实现细节,可能在未来发生变化,而且其中一些在现代Git中在某些情况下确实发生了变化,因此依赖于这些是不明智的。 但这就是它今天的实际工作方式。如果你运行git show xyz
,Git会尝试找到.git/refs/heads/xyz
,如果这不起作用,它会尝试在.git/packed-refs
中查找关于分支xyz
的行。Git还会尝试查找.git/refs/tags/xyz
和.git/xyz
。Git尝试执行这些操作的确切顺序是另一个实现细节,但实际上已经有记录了 - 在gitrevisions手册中描述了结果而不是方法。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中,当你处于一个由运行git worktree add ...
构建的已添加工作树中时,会出现问题。一个已添加的工作树的HEAD
不在.git/HEAD
中,而是在.git
的另一个子目录中。如果你在这个已添加的工作树中运行git show HEAD
,Git本身会看到所有大写字母的特殊名称HEAD
,并知道去查找正确的HEAD
,即此工作树的当前(right)HEAD
。但如果你运行git show head
,Git就看不到全大写的HEAD
,然后尝试打开各种文件,从.git/head
开始。如果这个成功了——它打开了.git/HEAD
——Git会读取主要工作树的分支,而不是你实际上在已添加的工作树上的分支。所以,在已添加的工作树中运行git show HEAD
会显示该工作树中的当前提交;但是,在相同的已添加工作树中运行git show head
会显示主工作树的当前提交,而不是该工作树的当前提交。git show head
根本不能工作。避免这个坏习惯:如果你不喜欢键入全大写的HEAD
,可以使用@
代替。git
的命令行中,你可以输入以下内容:
HEAD
是当前的提交,也就是当前在工作目录中被检出的提交。
head
这个词对于 GIT 而言没有任何意义,除非你有一个名为 head
的分支或标签。但这听起来像是一个坏主意。master
(或远程 HEAD 的 origin/master
),而不是字面上的单词 head
。HEAD
的大小写替代方案返回主工作树的分支,而不是多工作树环境中当前工作树的分支(这是另一个有趣的特例)。在CentOS 7(XFS)上,使用git版本2.16.5的HEAD
的替代版本会返回“fatal: ambiguous argument 'hEAD': unknown revision or path not in the working tree”。长话短说,只需使用HEAD
。 - Mike Hill
head
被用到。我认为它具有语义意义,但不是一个逐字逐句的命令。无论如何,我赞同你的答案,几乎和我自己想发表的一样。 - Tim BiegeleisenHEAD
在 Windows 上不区分大小写,这可能会导致混淆。 - pishpishHEAD
的地方使用head
。 - horseyguygit show hEad
等命令。在我的Git版本中,它们似乎都可以正常工作。 - horseyguy