git 没有在 ref 目录中包含所有分支文件并且没有在分支引用文件中维护提交 ID。为什么?

git is not having all branch files in ref dir AND not maintaining commit id in branch reference file. Why?

据我了解,GIT 使用名称与分支名称相同的纯文本文件跟踪分支。这些文件存储在 .git\refs\remotes\origin 中,用于远程跟踪远程分支,对于本地分支,这些文件存储在 .git\refs\heads

下面是 git 分支的输出:

$ git branch -a
  joincolumn_issue
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/joincolumn_issue
  remotes/origin/mappedBy
  remotes/origin/master
  remotes/origin/todelete

第一部分problem/questions:
正如您所看到的,有几个远程分支 git 知道......但是在查看 .git 目录时我没有看到所有这些分支 -

Samsh@Sambox MINGW64 /d/graphql-hibernate/.git/refs/remotes/origin (GIT_DIR!)
$ ls
HEAD  joincolumn_issue

为什么其他分支的文件不存在。行。 joincolumn_issue 以外的分支从未从远程结帐。所以如果是这个原因。好吧,如果确实如此,那么 git 如何以及从哪里获取其他分支详细信息(因为它在 git branch -a 中列出了它们,这绝对不是轮询此查询的回购)

problem/question的第二部分: 查看参考目录中文件的内容-

Samsh@Sambox MINGW64 /d/graphql-hibernate/.git/refs/remotes/origin (GIT_DIR!)
$ cat joincolumn_issue
1950d716308e5063f1b8f28c2423166781335333

这是指向提交 ID 的预期结果。美好的。但问题在于以下输出。

$ cat HEAD
ref: refs/remotes/origin/master

HEAD指的是master,.git目录下没有这个文件。所以现在你明白我的问题了,我看不出 git 如何在没有 knowing/tracking 相关提交 ID 的情况下找出 master 的提示。

GIT keeps track of branches using plain text files with name same as the branch name.

有时,是的。有时没有。你不应该关心。您为什么要检查 .git/refs/heads/ 个文件?1

Git 在某处有一个数据库,2,名称到哈希 ID 的映射。您可以使用 git rev-parse 程序从名称中提取哈希 ID:3

git rev-parse refs/heads/master

为您提供 refs/heads/master 的哈希 ID,即分支名称 master。您可以使用 git for-each-ref 遍历部分或所有引用(请参阅其文档)。

通常,您设置 名称以使用更高级别的接口来散列 ID,例如 git branchgit tag;但是你可以直接使用 git update-ref:

写数据库
git update-ref [flags] refs/heads/master <new-hash> [<old-hash>]

表示存储新的散列;如果我提供旧哈希,请确保名称映射到现有哈希 ID,然后再进行更改


1也许是在调试、学习,或者只是单纯的固执。 :-)

2在内部,在 C 代码中,Git 具有实现引用存储和加载的 "back ends" 的概念。当前的 "database" 真的很糟糕,由平面文件 .git/packed-refs 或取自 .git/refs/<path> 的文件组成。平面文件 "database" 工作正常——它分别存储名称 masterMASTER,例如,所以这两个分支是不同的,正如 Git 预期的那样——但是本地文件系统文件树 "database" 在某些无法创建同时命名为 master MASTER 的系统上严重失败。很明显,像 GitHub 这样的大型服务器提供商可以使用 real 数据库:一些存储库有数千个标签,处理平面文件和文件树是,应该我们说,"not good".

3Rev-parse 比 只是 在数据库中查找一个名字做的更多,但它确实做到了,所以为什么不用它?