记录对仓库的更改

到目前为止，我们应该在本地计算机上拥有一个真正的 Git 仓库，并且拥有所有文件的一个检出或工作副本。通常，我们会想要开始进行更改，并在项目达到想要记录的状态时，将这些更改的快照提交到我们仓库中。

请记住，工作目录中的每个文件都可能处于两种状态之一：已跟踪或未跟踪。已跟踪的文件是上次快照中的文件，以及任何新的暂存文件；它们可以是未修改、已修改或已暂存的。简而言之，已跟踪的文件是 Git 知道的文件。未跟踪的文件是其他所有文件 —— 工作目录中的任何文件，它们既不在上次快照中，也不在暂存区中。当首次克隆一个仓库时，所有文件都将被跟踪且未修改，因为 Git 只是将它们检出，而我们还没有编辑任何内容。

当我们编辑文件时，Git 将其视为已修改，因为自上次提交以来已对其进行了更改。在工作过程中，选择性地暂存这些已修改的文件，然后提交所有这些已暂存的更改，这个循环就会重复。

检查文件状态

确定文件处于哪种状态的主要工具是 `git status` 命令。如果在克隆后直接运行此命令，应该会看到类似以下的内容：

这表示工作目录是干净的，换句话说，已跟踪文件都没有被修改。Git 也没有发现任何未跟踪的文件，否则它们会在这里列出。最后，命令告诉我们当前所在的分支，并且通知我们它与服务器上相同分支没有发生分歧。目前，该分支始是master，这是默认的；暂时不需要担心这个问题。Git 分支将会详细介绍分支和引用。

注意：

GitHub 在 2020 年中期将默认分支名称从 master 更改为 main，其他 Git 主机也纷纷效仿。因此，你可能会发现一些新创建的仓库的默认分支名称是 main 而不是 master。此外，默认分支名称是可以更改的（所以我们可能会看到不同的默认分支名称。）但是，Git 本身仍然将 master 作为默认分支名称。

假设向项目中添加了一个新文件，一个简单的 README 文件。如果该文件之前不存在，并且运行 git status，将会看到如下未跟踪文件的信息：

可以看到新 README 文件是未跟踪的，因为它在状态输出中位于“未跟踪文件”部分下面。未跟踪基本上意味着 Git 发现了一个在之前的快照（提交）中没有的文件，并且该文件还没有被暂存；Git 不会开始将其包含在提交快照中，直到明确告诉它这样做。它之所以这样做，是为了避免意外地开始包含生成的二进制文件或其他不想包含的文件。如若确实想开始包含 README 文件，让我们开始跟踪该文件。

跟踪新文件

为了开始跟踪一个新文件，可以使用命令 git add。要开始跟踪 README 文件，可以运行以下命令:

$ git add README

如果再次运行状态命令，会发现README 文件现在被跟踪，并准备好提交。

可以通过它位于“将提交的更改”标题下来判断它已经暂存。如果在这一点上进行提交，那么运行 git add 时的文件版本将会成为随后历史快照中的内容。也许你还记得之前运行 git init 之后，运行了 git add <files> —— 那是为了开始跟踪目录中的文件。git add 命令接受文件或目录的路径名。如果是目录，则该命令会递归地添加该目录中的所有文件。

暂存修改后的文件

让我们修改一个已经被跟踪的文件。假设修改了一个之前被跟踪的文件 README.md，然后再次运行 git status 命令，会看到类似以下的输出：

README.md 文件出现在了一个名为 “Changes not staged for commit” 的部分下面，意味着这个文件是已跟踪的文件，但是在工作目录中被修改了并且还未暂存。要将其暂存，你需要运行git add`命令。git add`是一个多功能的命令 —— 可以使用它来开始跟踪新文件，将文件暂存，以及执行其他操作，比如标记解决了合并冲突的文件。可以把它理解为 将这个内容精确地添加到下一次提交中，而不仅仅是 将这个文件添加到项目中。让我们现在运行 git add`命令将README.md文件暂存，并再次运行 git status：

现在两个文件都已经暂存，并将在下一次提交中被包含。此时，假设想起在提交前还要对 README.md 进行一点小修改。重新打开了这个文件，做了修改，然后准备提交。然而，让我们再次运行 git status：

这到底是怎么回事？现在README.md 被同时列为已暂存和未暂存。这怎么可能？原来，Git 在运行 git add 命令时会将文件暂存，就是当前文件的状态。如果现在提交，README.md将以上次运行 git add 命令时的版本进入提交，而不是在运行 git commit 时工作目录中的文件版本。如果在运行 git add 后修改了文件，则必须再次运行 git add 来暂存文件的最新版本。

简要git status状态信息

虽然 git status 命令的输出非常详细，但也相当冗长。Git 还有一个简短的状态标志，因此可以以更紧凑的方式查看您的更改。如果运行 git status -s 或 git status --short，则可以从命令中获得大大简化的输出。

未跟踪的新文件旁边有一个 ??，已添加到暂存区的新文件有一个 A，修改过的文件有一个 M，等等。输出有两列 — 左边的列表示暂存区的状态，右边的列表示工作树的状态。

Ignoring Files

通常你会有一类文件，不希望 Git 自动添加，甚至不希望它们显示为未跟踪的文件。这些通常是自动生成的文件，比如日志文件或者构建系统生成的文件。在这种情况下，可以创建一个名为 .gitignore 的文件，其中列出了匹配这些文件的模式。以下是一个示例 .gitignore 文件：

第一行告诉 Git 忽略以 ".o" 或 ".a" 结尾的任何文件 —— 这些是可能是构建代码生成的对象和归档文件。第二行告诉 Git 忽略所有以波浪符 (~) 结尾的文件，许多文本编辑器如 Emacs 使用它来标记临时文件。还可以包括一个日志、tmp 或 pid 目录；自动生成的文档等。在开始新的存储库之前设置一个 .gitignore 文件通常是一个好主意，这样就不会意外提交真的不想要在 Git 存储库中的文件。

可以放在 .gitignore 文件中的模式的规则如下：

空白行或以 # 开头的行将被忽略。

• 标准的 glob 模式适用，并将在整个工作树中递归应用。
• 可以以斜杠 (/) 开始模式以避免递归。
• 可以以斜杠 (/) 结束模式以指定一个目录。
• 可以通过以感叹号 (!) 开始来否定一个模式。

Glob 模式类似于 shell 使用的简化正则表达式。星号 (*) 匹配零个或多个字符；方括号内的任何字符（在本例中为 a、b 或 c）；问号 (?) 匹配单个字符；以连字符分隔的字符括在方括号中（[0-9]）匹配它们之间的任何字符（在本例中为 0 到 9）。也可以使用两个星号来匹配嵌套目录；a/**/z 将匹配 a/z、a/b/z、a/b/c/z 等。

以下是另一个示例 .gitignore 文件：

# ignore all .a files

*.a

# but do track lib.a, even though you're ignoring .a files above

!lib.a

# only ignore the TODO file in the current directory, not subdir/TODO

/TODO

# ignore all files in any directory named build

build/

# ignore doc/notes.txt, but not doc/server/arch.txt

doc/*.txt

# ignore all .pdf files in the doc/ directory and any of its subdirectories

doc/**/*.pdf

如果想为项目找到一个起点，GitHub 维护了一个相当全面的 .gitignore 文件示例列表，涵盖了数十个项目和编程语言，地址是 https://github.com/github/gitignore。

在简单的情况下，一个存储库可能在其根目录中有一个单独的 .gitignore 文件，递归地应用于整个存储库。然而，也可以在子目录中有额外的 .gitignore 文件。这些嵌套的 .gitignore 文件中的规则仅适用于它们所在目录下的文件。Linux 内核源代码存储库有 206 个 .gitignore 文件。

超出本教程的范围来详细讨论多个 .gitignore 文件；参见 man gitignore 获取详细信息。

查看已暂存和未暂存的更改

如果 git status 命令太模糊了 —— 想要知道确切地改变了什么，而不仅仅是哪些文件被改变了 —— 可以使用 git diff 命令。我们稍后会更详细地介绍 git diff，但可能最常用它来回答以下两个问题：改变了什么但尚未暂存？暂存了什么准备提交？尽管 git status 通过列出文件名来非常笼统地回答了这些问题，但 git diff 则显示了确切添加和删除的行数 —— 即补丁，可以这么说。

假设再次编辑并暂存了 README 文件，然后编辑了 README.md 文件但没有暂存。如果运行 git status 命令，会再次看到类似以下的输出：

要查看已经改变但尚未暂存的内容，请输入 git diff 而不带其他参数：

该命令将工作目录中的内容与暂存区中的内容进行比较。结果会显示做出的但尚未暂存的更改。

如果想要查看已经暂存的内容，即将进入下一个提交的内容，可以使用 git diff --staged 命令。该命令将比较暂存的更改与上一次提交的内容：

需要注意的是，单独运行 git diff 并不会显示自上次提交以来所有的更改 —— 只会显示仍然未暂存的更改。如果已经暂存了所有的更改，git diff 将不会有输出。

举个例子，如果将 README.md 文件暂存，然后编辑它，可以使用 git diff 来查看文件中已暂存的更改和未暂存的更改。如果我们的环境如下所示：

执行git diff

执行git diff --cached

提交更改

现在暂存区已经设置好了，可以提交更改了。记住，任何仍然未暂存的内容 —— 也就是创建或修改过的文件，但自从编辑它们后还没有运行过 git add 的文件 —— 都不会包含在这个提交中。它们将保留为你磁盘上的修改文件。在这种情况下，假设上次运行 git status 时看到所有内容都已经暂存，所以准备提交更改。最简单的提交方式是输入 git commit：

现在已经创建了一个提交！可以看到提交给出了一些关于自身的输出：提交到了哪个分支（master），提交的 SHA-1 校验和是什么（463dc4f），有多少文件被改变，以及关于提交中添加和删除的行数的统计信息。

提交记录了在暂存区设置的快照。任何没有暂存的东西仍然保持修改状态；可以进行另一个提交来将其添加到历史记录中。每次执行提交时，都记录了项目的一个快照，以便以后可以恢复或进行比较。

跳过暂存区

虽然暂存区在精确制作提交时非常有用，但有时候在工作流程中可能会稍显复杂。如果想跳过暂存区，Git 提供了一个简单的快捷方式。在 git commit 命令中添加 -a 选项会让 Git 在执行提交之前自动暂存已跟踪的每个文件，跳过 git add 这一步骤：

注意，在这种情况下，不必在提交之前对 README.md 文件运行 git add。这是因为 -a 标志包括了所有已更改的文件。这很方便，但要小心；有时这个标志会导致包含不想要的更改。

移除文件

要从 Git 中删除一个文件，必须将它从被跟踪的文件中移除（更准确地说，将它从暂存区中移除），然后进行提交。git rm 命令可以实现这一点，并且还会从工作目录中移除该文件，这样下次查看时就不会将其视为未跟踪的文件。

如果简单地从工作目录中移除文件，它会出现在git status 输出的“未暂存的更改”区域中：

然后，如果运行 git rm，它会将文件的删除操作暂存起来。

下次提交时，该文件将被删除并且不再被跟踪。

如果修改了文件或已将其添加到暂存区，必须使用 -f 选项来强制删除。这是一种安全特性，用于防止意外删除尚未记录在快照中且无法从 Git 中恢复的数据。

另一个可能想要做的有用的事情是保留文件在工作树中，但将其从暂存区中移除。换句话说，可能想要保留文件在硬盘上但不再由 Git 跟踪。如果忘记将某些内容添加到 .gitignore 文件并意外地将其暂存，比如一个大型日志文件或一堆 .a 编译文件，这种情况特别有用。为此，使用 --cached 选项：

可以将文件、目录和文件通配符模式传递给 git rm 命令。这意味着可以执行以下操作：

$ git rm log/\*.log

注意 * 前面的反斜杠 (\)。这是必要的，因为 Git 会执行自己的文件名扩展，除了 shell 的文件名扩展。这个命令删除 log/ 目录中所有具有 .log 扩展名的文件。或者，可以这样做：

git rm \*~

这个命令删除所有以 ~ 结尾的文件。

移动文件

与许多其他版本控制系统不同，Git 不会明确地跟踪文件的移动。如果在 Git 中重命名一个文件，Git 不会存储任何元数据来告诉它重命名了文件。然而，Git 在事后相当聪明地弄清楚了这一点 —— 我们稍后会处理检测文件移动的问题。

因此，Git 有一个 mv 命令有点令人困惑。如果想在 Git 中重命名一个文件，可以运行类似以下的命令：

$ git mv file_from file_to

而且它可以正常工作。事实上，如果运行类似这样的命令并查看状态，会发现 Git 认为它是一个重命名的文件。

然而，这相当于运行类似以下的命令

$ mv README.md README

$ git rm README.md

$ git add README

Git会隐式地推断出这是一个重命名操作，因此无论是用这种方式还是使用mv命令重命名文件都没关系。唯一真正的区别是git mv是一个命令，而不是三个命令——这是一个方便的功能。更重要的是，可以使用任何喜欢的工具来重命名一个文件，在提交之前再处理add/rm操作。