执行 git add 后如何撤回

很多刚开始使用 git 的程序员都不知道执行完 git add -A 后，该怎么撤回，那说明对 git reset 命令还没不够了解。该命令的格式有两种，

第一种的格式如下：

git reset [-q] [<tree-ish>] [--] <pathspec>…​

此表单将所有路径与 <pathspec> 匹配的 index 项重置为<tree-ish>的状态。（它不会影响工作树或当前分支。）

这意味着 git reset <pathspec> 是 git add <pathspec> 的反向操作。此命令等效于 git restore [--source=<tree-ish>] --staged <pathspec>...

在运行 git reset <pathspec> 更新 index 条目后，可以使用 git-restore[1] 将 index 中的内容检出到工作树中。或者，使用 git-restore[1] 并使用 --source 指定一个 commit ，您可以一次性将一个 commit 中路径的内容复制到 index 和工作树。

重点来了，如果你使用了类似 git add main.c 的命令，则直接使用 git reset -- main.c 就可以撤回，它的意思是把当前分支 HEAD 所指向的 main.c 文件覆盖暂存区中的 main.c , 这样暂存区中的main.c就跟版本库一样了。但大部分时候你可能会使用 git add -A , 那要撤回还得看第二钟格式：

git reset [<mode>] [<commit>]

此表单将当前分支 head 重置为 <commit> ，并根据<mode> 可能会更新 index （将其重置为<commit> 所指向的树）和工作树。在操作之前，ORIG_HEAD 被设置为当前分支的顶端。如果省略了<mode>，则默认为 --mixed 。<mode> 必须是下面中的一种：

• --soft
  完全不接触 index 文件或工作树（但将 head 重置为<commit>，就像 all modes 一样）。这使得所有更改后的文件都是 “Changes to be committed” ，正如 git status 所返回的那样。

• --mixed
  重置 index ，但不重置工作树（即，已更改的文件被保留，但未标记为 commit ），并报告尚未更新的内容。这是默认操作。

  如果指定 -N ，删除的路径将标记为 intent-to-add (see git-add[1])

• --hard
  重置 index 和工作树。自<commit>以来，对工作树中被跟踪文件的任何更改都将被丢弃。任何未跟踪的文件或目录在写入任何跟踪的文件时都会被简单地删除。

• --merge
  重置 index 并更新工作树中与 <commit> 和 HEAD 之间不相同的文件，但保留 index 和工作树之间不同的那些文件（即，具有尚未添加的更改）。如果<commit>和 index 之间不同的文件有未staged的更改，则重置将中止。

  换句话说，--merge做一些类似于 git read-tree -u -m <commit> 的事情，但将未合并的 index 项结转到前面。

• --keep
  重置 index 项，并更新工作树中与 和 HEAD 之间不同的文件。如果与 和 HEAD 之间不同的文件具有本地更改，则重置将中止。

• --[no-]recurse-submodules
  当工作树更新时，使用 --recurse-submodules 还将根据超级项目中记录的 commit 来递归重置所有活动子模块的工作树，并将子模块的 HEAD 在该 commit 处设置为分离头指针状态。

重点来了，如果你使用的是 git add -A ,要撤回直接使用 git reset 即可。它的意思就是用当前分支 HEAD 处的版本库重置暂存区，让暂存区与版本库保持一致，而工作区保持不变。