Git 工作原理，你要知道的Git知识！

我一直在非常缓慢地撰写有关 Git 工作原理的文章。我以为我 已经非常了解 Git，但像往常一样，当我试图解释一些事情时，我已经 一直在学习一些新东西。

回想起来，这些事情都不是超级令人惊讶，但我没有想到 之前清楚地了解他们。

事实是：

• “index”、“staging area”和“–cached”都是一回事
• 藏匿处是一堆提交
• 并非所有引用都是分支或标记
• 合并提交不为空

让我们来谈谈它们！

“index”、“staging area”和“–cached”都是一回事

当你运行 ，然后 ，你会看到如下内容：git add file.txt|git status

$ git add content/post/2023-10-20-some-miscellaneous-git-facts.markdown
$ git status
Changes to be committed:
  (use "git restore --staged ..." to unstage)
	new file:   content/post/2023-10-20-some-miscellaneous-git-facts.markdown

人们通常称其为“暂存文件”或“将文件添加到暂存区域”。

当您使用 暂存文件时，在后台 git 会将文件添加到其对象中 数据库 （in ） 并更新一个文件，调用以引用 新添加的文件。git add|.git/objects|.git/index

这个“暂存区”实际上在 Git 中被 3 个不同的名称引用。都 其中指的是完全相同的东西（文件）：.git/index

• git diff --cached
• git diff --staged
• 文件.git/index

我觉得我应该早点意识到这一点，但我没有，所以就是这样。

藏匿处是一堆提交

当我跑去藏我的更改时，我总是有点困惑 关于这些变化的实际去向。事实证明，当你运行时，git 会对你的更改进行一些提交，并用引用标记它们 称为 （in ）。git stashgit stashstash.git/refs/stash

让我们把这篇博文藏起来，看看参考的日志：stash

$ git log stash --oneline
6cb983fe (refs/stash) WIP on main: c6ee55ed wip
2ff2c273 index on main: c6ee55ed wip
... some more stuff

现在我们可以看一下提交，看看它包含什么：2ff2c273

$ git show 2ff2c273  --stat
commit 2ff2c273357c94a0087104f776a8dd28ee467769
Author: Julia Evans <julia@jvns.ca>
Date:   Fri Oct 20 14:49:20 2023 -0400

    index on main: c6ee55ed wip

 content/post/2023-10-20-some-miscellaneous-git-facts.markdown | 40                                         

不出所料，它包含这篇博文。 有道理！

git stash实际上创建了 2 个单独的提交：一个用于索引，一个用于 您尚未暂存的更改。我发现这种振奋人心的感觉 因为我一直在开发一个工具来快照和恢复 git 的状态 存储库（我可能会也可能不会发布），我想出了一个非常 类似的设计，所以这让我对自己的选择感觉更好。

显然，存储中较旧的提交存储在 reflog 中。

并非所有引用都是分支或标记

Git 的文档通常以一种通用的方式引用“引用”，我发现 有时有点令人困惑。就我个人而言，99% 的时间当我处理 在 Git 中，它是“引用”，或者另外 1% 的时间是标签。我 实际上不知道任何不是分支或标签的引用示例。HEAD|HEAD

但现在我知道一个例子——藏匿处是一个参考，而不是一个分支 或标签！所以这很酷。

以下是我博客的 git 存储库中的所有参考资料（除了）：HEAD

$ find .git/refs -type f
.git/refs/heads/main
.git/refs/remotes/origin/HEAD
.git/refs/remotes/origin/main
.git/refs/stash

在回复这篇文章时提到的其他一些参考资料：

• refs/notes/*从git notes
• refs/pull/123/head和 ‘ 用于 GitHub 拉取请求（你可以通过refs/pull/123/headgit fetch origin refs/pull/123/merge)
• refs/bisect/*从git bisect

合并提交不为空

这是一个玩具 git 存储库，我在其中创建了两个分支和 ，每个分支有 1 个 文件（和）并合并它们。让我们看一下合并提交。xyx.txty.txt

$ git log --oneline
96a8afb (HEAD -> y) Merge branch 'x' into y
0931e45 y
1d8bd2d (x) x

如果我运行 ，提交看起来“空”：没有差异！git show 96a8afb

git show 96a8afb
commit 96a8afbf776c2cebccf8ec0dba7c6c765ea5d987 (HEAD -> y)
Merge: 0931e45 1d8bd2d
Author: Julia Evans <julia@jvns.ca>
Date:   Fri Oct 20 14:07:00 2023 -0400

    Merge branch 'x' into y

但是，如果我将合并提交与它的两个父提交中的每一个进行比较 另外，你可以看到当然有一个差异：

$ git diff 0931e45 96a8afb   --stat
 x.txt | 1  
 1 file changed, 1 insertion( )
$ git diff 1d8bd2d 96a8afb   --stat
 y.txt | 1  
 1 file changed, 1 insertion( )

回想起来，合并提交实际上并不是“空的”，这似乎是显而易见的 （它们是存储库当前状态的快照，就像任何其他快照一样 commit），但我从未想过为什么它们看起来是空的。

显然，这些合并差异为空的原因是合并差异仅显示冲突 – 如果我创建一个存储库 与合并冲突（添加了一个分支，另一个分支添加到 相同的文件），并显示我解决冲突的合并提交，它看起来 喜欢这个：xy

$ git show HEAD
commit 3bfe8311afa4da867426c0bf6343420217486594
Merge: 782b3d5 ac7046d
Author: Julia Evans <julia@jvns.ca>
Date:   Fri Oct 20 15:29:06 2023 -0400

    Merge branch 'x' into y

diff --cc file.txt
index 975fbec,587be6b..b680253
--- a/file.txt
    b/file.txt
@@@ -1,1 -1,1  1,1 @@@
- y
 -x
  z

看起来这是在试图告诉我一个分支添加了另一个分支 分支添加，合并提交通过放置来解决它。但 在前面的示例中，没有冲突，因此 Git 根本没有显示差异。