Git:dev和refs/heads/dev之间有什么区别？

从devops最近的工作来看，似乎有“两种方法”可以在git中检出分支：使用普通的分支名称，例如

dev

，或者使用前缀为

refs/heads/

，例如

refs/heads/dev

两者之间有什么区别？

Bitbucket webhook中向Jenkins发送的某些HTTP POST内容给出了分支的“

refs/head

”版本。其他帖子内容给出了“basename”分支。
例如，使用（我认为是）Jenkins语法从pull request Bitbucket事件中获取帖子内容，

$.pullRequest.fromRef.id

=

/refs/heads/dev

..
和

$.pullRequest.fromRef.displayId

=

dev

在克隆存储库中，签出

refs/heads/dev

和

dev

解析为相同的SHAID，但它们各自的

stdout

不同：

$ git checkout refs/heads/dev
Note: checking out 'refs/heads/dev'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at c320fd1... wip

---

前者的

stdout

看起来与签出SHAID时相同。

名称被解析为修订id的早期版本，根据

当您给出的ref通过（仅）添加

refs/heads/

前缀来解析时，Git的便利机制开始发挥作用，

Git checkout

将使

HEAD

成为分支提示的别名，因此所有依赖

HEAD

的便利命令都将引用并更新分支提示ref

因此，当你说

git checkout dev

时，你正在使用git的便利机制，它为你做方便的事情，它连接

HEAD

作为

refs/heads/dev

的符号引用，

git commit

的

HEAD

更新将重定向到该分支提示

但是如果你通过自己采取明确的步骤来绕过便利逻辑，那就不会发生。这是唯一的区别。如果你愿意，你可以

git checkout refs/heads/dev 
git symbolic-ref HEAD refs/heads/dev

---

现在您已经自己完成了Git的便利处理。

没错。这就是结账的工作方式。即使c320fd1是dev，也会分离签出c320fd1，但签出dev不是。它们命名相同的提交，但它们不是同义词。关于那件事，没什么可知道的了。这只是游戏规则。与refs/heads/dev和dev类似，后者指前者<代码>cat.git/refs/heads/dev并参见。Git在refs/heads中查找dev。但它们不是同义词。

git checkout refs/heads/dev 
git symbolic-ref HEAD refs/heads/dev