HEAD以及分离头指针

发表于2026-04-09|更新于2026-04-09|工具

|浏览量:

HEAD 是一个对当前检出记录的**符号引用** —— 也就是**指向你正在其基础上进行工作的提交记录**。HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。

HEAD 通常情况下是指向分支名的（如 bugFix）。在你提交时，改变了 bugFix 的状态，这一变化通过 HEAD 变得可见。

git checkout c1
git checkout master 
git commit -m "c2"
git checkout c2

如果想看 HEAD 指向，可以通过 cat .git/HEAD 查看

分离的 HEAD

**分离的 HEAD 就是让其指向了某个具体的提交记录而不是分支名。**在命令执行之前的状态如下所示：

HEAD -> master -> C1

HEAD 指向 master， master 指向 C1

1	git checkout c1

现在变成了

HEAD -> C1

文章作者: 褚成志

文章链接: https://blog.chucz.asia/2026/04/09/HEAD%E4%BB%A5%E5%8F%8A%E5%88%86%E7%A6%BB%E5%A4%B4%E6%8C%87%E9%92%88/

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源褚成志的分享站！

Git 版本控制

相关推荐

git：rebase、merge

git：rebase 、mergegit merge–会有新的提交**在 Git 中合并两个分支时会产生一个特殊的提交记录，它有两个父节点。**翻译成自然语言相当于：“我要把这两个父节点本身及它们所有的祖先都包含进来。” 1234# 在master分支上git merge bugFix# 会生成一个新的提交在master上面 1234# 在bugfix去mergemaster，因为之前master已经合并了，所以直接快速合并git checkout bugFixgit merge master 因为 master 继承自 bugFix，Git 什么都不用做，只是简单地把 bugFix 移动到 master 所指向的那个提交记录。现在所有提交记录的颜色都一样了，这表明每一个分支都包含了代码库的所有修改 rebase–不会生成新的提交不要在master使用，在自己的分支使用即可 merge更加关注历史记录 git rebase。Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。 Rebase 的优势就是可以创造更线性的提交历史...

指定哈希与相对引用

指定hash通过指定提交记录哈希值的方式在 Git 中移动不太方便。用 git log 来查查看提交记录的哈希值。哈希值在真实的 Git 世界中也会更长（基于 SHA-1，共 40 位）。可以仅输入fed2 而不是 fed2da64c0efc5293610bdd892f82a58e8cbc5d8一长串字符。通过哈希值指定提交记录很不方便，所以 Git 引入了相对引用。使用相对引用的话，你就可以从一个易于记忆的地方（比如 bugFix 分支或 HEAD）开始计算。使用 ^ 向上移动 1 个提交记录使用 ~<num> 向上移动多个提交记录，如 ~3 相对引用操作符 ^把这个符号加在引用名称的后面，表示让 Git 寻找指定提交记录的父提交。所以 master^ 相当于“master 的父节点”。master^^ 是 master 的第二个父节点现在咱们切换到 master 的父节点 1git checkout master^ 1234git checkout C3git checkout HEAD^git checkout HEAD^git checkou...

远程仓库操作

git clone远程仓库： git clone 远程使用虚线表示本地仓库多了一个名为 o/master 的分支, 这种类型的分支就叫远程分支。远程分支反映了远程仓库(在你上次和它通信时)的状态。远程分支有一个特别的属性，在你检出时自动进入分离 HEAD 状态。Git 这么做是出于不能直接在这些分支上进行操作的原因, 你必须在别的地方完成你的工作, （更新了远程分支之后）再用远程分享你的工作成果。为什么有 o/？远程分支有一个命名规范 —— 它们的格式是: <remote name>/<branch name> 因此，如果你看到一个名为 o/master 的分支，那么这个分支就叫 master，远程仓库的名称就是 o。大多数的开发人员会将它们主要的远程仓库命名为 origin，并不是 o。这是因为当你用 git clone 某个仓库时，Git 已经帮你把远程仓库的名称设置为 origin 了不过 origin 对于我们的 UI 来说太长了，因此不得不使用简写 o :) 但是要记住, 当你使用真正的 Git 时, 你的...

gitreset、revert

git reset、revertgit resetgit reset 通过把分支记录回退几个提交记录来实现撤销改动。你可以将这想象成“改写历史”。git reset 向上移动分支，原来指向的提交记录就跟从来没有提交过一样。 1git reset HEAD~1 Git 把 master 分支移回到 C1；现在我们的本地代码库根本就不知道有 C2 这个提交了。在reset后， C2 所做的变更还在，但是处于未加入暂存区状态。 git revert虽然在你的本地分支中使用 git reset 很方便，但是这种“改写历史”的方法对大家一起使用的远程分支是无效的为了撤销更改并分享给别人，我们需要使用 git revert。 1git revert HEAD 在我们要撤销的提交记录后面居然多了一个新提交！这是因为新提交记录 C2’ 引入了更改 —— 这些更改刚好是用来撤销 C2 这个提交的。也就是说 C2’ 的状态与 C1 是相同的。 revert 之后就可以把你的更改推送到远程仓库与别人分享啦。注意reset是HEAD^，而revert是HEAD

git快捷命令配置

1vim ~/.gitconfig 1234567891011121314151617 1 [user] 2 name = deltaqin 3 email = delta_qin@163.com 4 [core] 5 autocrlf = input 6 [alias] 7 co = checkout 8 br = branch 9 ci = commit 10 st = status 11 dog = log --all --decorate --oneline --graph 12 [http] 13 proxy = http://127.0.0.1:1087 14 [https] 15 proxy = http://127.0.0.1:1087~~ 12345git config --global alias.st status //status 缩写成 stgit config --global alias.co checkout //checkout 缩写成 cog...

git思维导图总结

导图有笔记 https://www.processon.com/view/link/60ab180a5653bb690f73a0fa 新建仓库新建的时候最好有文件合并分支mergedev和master分支都有修改的话，使用git log只能看到自己的分支的log git merge dev 当前是在master分支的，结果如下：可以看到是新建了一个分支。最为master当前的分支，但是dev还是在自己的分支。一般不会在master修改，也就是裸仓库。只是用来合并的。修改dev分支的内容提交，回到master合并产生冲突了，修改之后 git add test1 git commit 再次查看，所以就是master是不会修改的。只在Dev分支做修改，修改了之后merge上去后面的内容直接看导图为什么建议多分支Git 的分支也非常轻量。它们只是简单地指向某个提交纪录 —— 仅此而已。所以许多 Git 爱好者传颂：早建分支！多用分支！这是因为**即使创建再多的分支也不会造成储存或内存上的开销**，并且按逻辑分解工作到不同的分支要比维护那些特别臃肿的分支简单多了。

数据加载中