重新运行 git status 无法正常工作

Initial commit 和 No commits yet 代表来自 git status 的相同事物。旧版本的 Git 说前者；新版本的 Git 说后者。当 Git 人员发现 Git 新手发现 No commits yet 消息更易于理解时，他们更改了它。既然您说的是 No commits yet，那么您只是拥有比编写您的指令的人更新的 Git 版本。

未跟踪文件是不在 Git 的索引中的文件。如果您希望该文件出现在您的下一次提交中，您必须使用 git add 将该文件添加到 Git 的索引。

在 Git 中，索引是一件大而复杂的事情，但作为一个 Git 新手，现在有一个简单的方法来考虑它：Git 的索引保存您提议的下一次提交。这个索引的东西很重要，它有三个名字：

• 索引（正如我在上面使用的那样）；或
• 暂存区：这描述了您将如何使用索引；或
• 缓存。

这个姓氏现在非常少见，主要作为各种 Git 命令的标志出现，例如 git diff --cached 或 git rm --cached。但是这三个名字实际上指的是同一个东西。¹

这里要意识到的是，一旦您进行提交，您存储在中提交的文件将永久存储作为只读存档.² 所以它们变得“安全”：如果你把事情搞砸了，你可以把它们找回来。这些文件的提交存档版本实际上无法更改，甚至 Git 本身也无法更改。它们以一种特殊的、只读的、压缩的和去重格式存储，您的计算机本身也无法读取：只有 Git 可以读取它们，而没有任何东西可以写入它们（除了每次提交仅创建一次存档）。

因为提交的文件实际上不能使用，你必须让 Git 从提交中复制它们，然后才能使用提交。所以这就是 git checkout 或新的（Git 2.23 或更高版本）git switch 所做的：它复制提交的文件，以便您可以看到它们并使用它们。 >

您可以看到和使用的副本存在于 Git 所谓的工作树中。这些文件是普通的、日常的文件，每个程序都可以正常读写。这些是您用来完成工作的文件。

Git 索引的棘手之处在于，Git 始终保持每个文件的第三个副本。提交中有一份副本，而您的工作树中每天都有一份。但是在这两者之间，Git 有每个文件的额外index 副本。此索引“副本”已预先删除重复数据，因此 git commit 会运行得很快——并且实际上不会为与旧的、已提交的文件相同的文件占用任何空间文件。但是每个文件的每个索引副本总是存在。它就在那里，准备好了，准备在下一次提交中提交。

这就是使索引成为您建议的下一次提交的原因：它保存了每个文件的副本，准备提交。当您运行 git commit 时，Git 不会查看您的工作树文件。它查看 Git 索引中的副本并将其保存为新的存档/提交。

在您运行 git add 之前，任何给定文件的索引副本都与您检出的提交副本相匹配。如果没有检出提交的副本，则该文件甚至还没有在 索引中。因此，如果您在工作树中创建了一个新文件，但它不在 Git 的索引中，Git 会将其列为 untracked.³

¹一个 Git 命令 git apply 在其 --index 和 --cached 标志之间做了额外的区分，但对于 git diff，{{ 1}} 和 --staged 的意思完全一样。

²从技术上讲，它们只会在提交本身存在时才存储，但通常是“永远”。稍后再担心此规则的例外情况。

³最终，您会发现一长串未跟踪的文件很烦人。有一种方法可以让 --cached 对一些未跟踪的文件闭嘴。不过留到以后再说吧。