为什么“git commit -a”是有时需要代替“git commit”？

Question

在使用 Git 和 GitHub 时，我发现有时

git commit -a

需要 a 来提交修改的文件。 （该文件已添加到项目中）。

但有时，只需一个

git commit

意志就可以了。如果使用 Mercurial，并且命令 hg com 始终有效（如果它是之前已添加到存储库中的文件）。所以我想知道为什么 git 有时需要 -a ？在一些解释中出现了“暂存”这个词，但我不完全理解暂存的概念以及它与对文件提交一些修改有何关系？

Answer 1

仔细查看 git commit 的手册页 是这样描述的：

• 当你向 git 添加一个新文件时，你可以使用 git add 来完成。这标记了要在下次提交时添加的文件（以及 git rm 用于删除文件的操作）。
• 当您更改文件时，您还可以执行 git add 来将其标记为下一次提交，但通常您不会这样做。在这种情况下，git commit -a 会为您完成这项工作：
  <块引用>

  告诉命令自动暂存已修改和删除的文件，但你没有告诉 git 的新文件不受影响

示例：如果您只想对某些已修改的文件进行提交（例如，您修复了影响两个文件的错误（one.c、two.c）并删除了其他文件中的一些拼写错误，并且希望将错误修复签入与拼写错误签入分开），您将为每个文件执行 git add错误修复文件，然后提交：

git add one.c
git add two.c
git commit -m "bugfix checkin" 

完成此操作后，您可以使用

git commit -a -m "fixed typos"

关于登台：
提交拼写错误修复
git commit 仅提交以某种方式标记为要提交的文件。例如，这可以通过 git add 或 git rm 来实现。这种提交标记称为“暂存”。

Answer 2

假设您对文件进行了两次不同的逻辑更改，但只想提交其中之一。如果“git commit”总是提交它所知道的所有文件，那么该行为将是不可能的。因此，您需要在提交之前暂存每个更改。如果您“git add filename”，则您将暂存该文件中的所有更改。顺便说一句，“git stage”是“git add”的同义词，如果您使用“git stage”代替，它可能会使操作更清晰。

将暂存区域（索引）视为工作目录和存储库之间的中间区域。命令“git add”和“git stage”将内容移动到索引中，“git commit”将它们从索引移动到存储库。 “git commit -a”同时执行这两个步骤。能够使用暂存区域来帮助完善您的提交，以便您准确地提交您想要的内容通常非常有用。

Answer 3

另请参阅文章“您本可以发明 git（也许您已经发明了！）”：当您将索引视为“补丁数据库”时，它会有所帮助。

如果您“添加”一个文件（到“索引”，也称为“暂存区域”），您实际上添加了由该文件中所做的演变所代表的补丁。
如果您在将同一个文件添加到索引后对其进行了新的改进，您实际上正在做一个新的补丁（包含自上次“git add”），并且在您能够提交之前需要添加这些新的演变（到索引，“补丁数据库”）。
或者在这种情况下你可以直接使用 git commit -a 。

Answer 4

要了解 git commit 和 git commit -a 之间的区别，您需要了解 git 中的索引，也称为>暂存区。

索引本质上存储将进入下一次提交的每个文件的状态。 （这里的“状态”是指文件的确切内容，git 通过其哈希来识别。）当您键入 git commit 且不带任何其他参数时，git 将进行一次新的提交，其中所有文件的状态与索引中的完全相同。这可能与您的工作树非常不同，这是 git 的一个有用功能，我将在下面解释。

git add 真正做的是“暂存”一个文件，或者将其当前状态添加到索引中。它最初是否被跟踪并不重要，您是在说“在下一次提交中，我希望该文件以完全相同的内容出现”。重要的是要认识到，这记录了您想要添加的内容，而不是文件名 - 这意味着如果您在使用 git add 暂存文件后继续对文件进行更改，那么您'你会看到 git status 的输出，这些输出有时会让来自其他版本控制系统的人感到困惑：

$ git status
[...]
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#   modified:   foo.txt
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   foo.txt

...但如果你了解索引，这绝对有意义。您可以通过以下方式查看已经暂存的更改（即索引和 HEAD 中的文件状态之间的差异，这通常是您正在处理的分支上的最后一次提交）：

$ git diff --cached

...并且您可以看到所有尚未上演的更改（即工作副本和索引之间的差异）：

$ git diff

那么为什么这如此有用？从本质上讲，这个想法是，当每次提交仅包含一组逻辑分组的更改（这些更改可以对项目进行明确的改进）时，项目的历史记录是最有用的。这些提交越小越好，因为后来这个出色的工具 git bisect 可以快速帮助您追踪哪个更改引入了错误。除非您非常自律，否则在修复错误的过程中，您通常会最终编辑其他实际上不需要更改的文件来修复问题，或者可能最终会修复两个逻辑上不同的问题决定提交您的更改。在这些情况下，索引可以帮助您分离出这些更改 - 只需 git add 每个包含您想要在第一次提交中进行的更改的文件，运行 git commit，然后执行同样创建第二次提交。 [1]

如果您习惯这样做并且喜欢工作流程，那么有时您最终会只想将一些更改暂存到文件中而不是其他更改，在这种情况下您会想要了解git add -p（然后是其交互式s和e选项！）

但是，回到最初的问题 - git commit -a 有何不同？本质上它是说，“在创建此提交之前，还将已修改（或删除）的每个文件暂存为其当前状态。”因此，如果您认为在提交之前在索引中仔细暂存文件没有用，您可以一直使用“git commit -a”。然而，我认为使用 git 的好处之一是它鼓励您创建美丽的提交，而积极使用索引对此有很大帮助。 :)

---

注释：

为了使上述解释简单，有些陈述有些近似（例如，我没有提到索引还存储文件的（非）可执行状态，即它在合并期间可以有多个版本，等等。）

[1] 如果您想确保历史记录中的每个提交都经过正确测试，那么您应该小心执行此操作 - 如果这在您的项目中很重要，您应该测试在推送之前在每个新提交处树...

Answer 5

查看常见问题解答。简而言之，它使 git 更加灵活。