git获取数据存储在哪里？

Question

我是git的新手,我正在努力理解它的概念.

refspec - 据我所知,将服务器分支映射到"本地"目标分支.

我写了"本地",因为如果我们"git fetch"它们不会与我们的工作副本或临时区域合并,它们会被保存在其他地方.

所以我的问题是

A)它们存储在.git/refs/remotes/origin /(分支机构)吗？

B)如果是,每个.git/refs/remotes/origin /(分支)的内容是对服务器中更改所在地的引用/ ID？

在.git/refs/remotes/origin /中的一个分支中我找到了这个:761db53af177ecfd9c9b14511360537e041ebed7

C)当我们进行提交时,更改保存在哪里？

它们存储在.git /对象中吗？

Answer 1

这些在其他地方得到了零碎的回答，但我会继续在这里输入一个简短的¹个多合一的答案：

refspec - 据我所知，将服务器分支映射到“本地”目标分支

这是一个效果，而不是一个定义。

refspec的定义只是一对引用名称，由冒号分隔:，并带有可选的前导加号+。冒号左边的引用名称是源，右边的名称是目标。如果存在前导加号，则 refspec 说 Git 应该执行“强制更新”，即更新引用，即使它不是快进（分支引用）或自然不允许（对于标签）。

Refspecs 用于git fetch和git push。省略其中一个部分在不同的命令中会产生不同的效果，因此最容易使用双方都完整的 refspecs。与 一起使用时git fetch，源确实是服务器的引用（通常是分支名称，但您可以复制标签、注释或服务器公开的任何其他引用——默认情况下，服务器公开所有内容）。正如您所猜测的，目的地是您自己的本地参考，通常也是一个分支名称。

你的第一个问题：

A) 它们是否存储在 .git/refs/remotes/origin/(branches)？

默认情况下，是的。但请注意几个警告：

• 要查找.git目录，请使用git rev-parse --show-toplevel或git rev-parse --show-cdup如果您在子目录中。
• 引用名称可能会被打包，在这种情况下，它们不会存储在它们自己的单独文件中。
• Git是（内部）不断发展的一个可插拔的后端的REF-的名字，因此，即使上述如有更改：从脚本解决或更新REF-的名字，你应该使用Git的“管道”的命令，即git rev-parse，git symbolic-ref和git update-ref。

上面限定符的“默认”部分是因为目标名称实际上是一个配置项。对于远程 named origin，git fetch默认使用配置的remote.origin.fetch值：

$ cd [path to git repo for git]
$ git config --get-all remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
$ cd [path to git repo for FreeBSD]
$ git config --get-all remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
+refs/notes/*:refs/notes/origin/*
$ 

如上所示，对于任何给定的遥控器，您可以有多个 fetch配置。

（对于名为 的远程$rem，请使用git config --get-all remote.$rem.fetch查看其默认获取 refspecs。）

如上所示，fetch refspecs 可能包含通配符*。这些工作很像 shell（sh、bash、zsh 等）“glob”字符，除了在旧版本的 Git ^{2 中，}它们被限制在斜杠之后立即出现/（例如，refs/heads/pr*将被禁止），当然当它们出现时在目标端，它们只是扩展回它们在源端匹配的任何东西，因此它们必须配对。

B）如果是，每个 .git/refs/remotes/origin/(branch) 的内容是服务器中更改位置的引用/ID？

排序：它是一个对象标识符。（这个问题的确切形式暗示了一个错误的假设，我们稍后会谈到。）

因为refs/remotes/origin/$branch是远程跟踪分支名称（因此是refs/heads/命名空间分支名称的副本），所以它实际上必须指向³一个提交对象。请注意，名称在 中的位置refs/决定了引用的类型。引用类型暗示了对象类型：大多数名称通常应该指向提交对象，但标记名称可以指向四种基本对象类型中的任何一种。（四种类型是commit、tree、blob和tag或“带注释的标签”；标签名称通常应直接指向提交或带注释的标签对象。一次提交指向父提交和一棵树；树指向斑点和额外的树；和 blob 包含文件内容。另请参阅问题 C 的答案。）

C）当我们进行提交时，更改保存在哪里？

这就是你偏离轨道、陷入杂草的地方：Git 保存快照，而不是更改。 但你大多是在正确的区域！

一张图片胜过千言万语，因此我将提供Pro Git 书籍章节的链接。

它们存储在 .git/objects 中吗？

这是 Git 存储其“目标文件”的地方，是的。一个新的提交意味着一个新的对象，新的对象进入那个目录（实际文件名被复杂化⁴以使 Git 在 Linux 机器上运行得更快，其中“胖”目录很慢）。如上所述，新提交指向一棵树——通常是一个新的树对象，而不是一些现有的树对象——并且该树提供了从正常用户文件名（和文件模式，特别是执行位）到 Git blob 的映射。对象名称。树和 blob 对象也存储在.git/objects.

然而，更复杂的是，对象可能被打包到一个“打包文件”中。（此时，Git确实开始进行增量压缩，就像其他版本控制系统一样，但有一个显着的变化，即增量压缩不需要应用于“相同”文件的先前版本，甚至文件的在实践中，选择 delta 链的启发式目前与文件名和大小相关联，但原则上，我们可以针对树压缩文件，反之亦然，如果效果很好。）

¹短如“写作时间”，而不是“答案长度”。:-) 如果我花更长的时间，我可以写一个更短的答案......

²在 Git 2.5 左右的某个地方，但我没有时间查找放宽通配符放置限制的确切版本。

³这里的短语“point to”是“contain the ID of”的缩写，暗示我们——或Git——可以跟随这个ID来找到对象本身，就像跟随一个指向箭头：这条路到出口对象.

⁴向非英语母语人士致歉：这不是一个真正的词，而是“complex”和“complication”的混合词，副词后缀“-ify”加了两次，用胶水、锉刀和砂纸打磨以适应，只是使并发症复杂化。:-)