问git reset vs git reset HEAD

EN

默认参数(与git reset man page)无差异：

在所有形式中，<tree-ish>/<commit>默认为HEAD。

该消息最初不包括HEAD：commit 3c1eb9c, Jan. 2007, git 1.5.0-rc1，但由于默认值并不总是已知的，帮助消息清楚地表明您应该重置哪个提交。

commit 367c988, Nov. 2007, Git 1.5.4中出现HEAD

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)

torek指出了一个实际的差异in the comments

通过指定HEAD，您可以保证将HEAD之后的第一个单词作为路径名。

例如，假设您运行git reset zorg。zorg是树型的，比如标记名，还是路径名，./zorg？

Git的答案是:如果git rev-parse可以将它转换为树ID，那么它就是一个类似树的东西，否则它就是一个路径。

您可以编写git reset -- zorg或git reset HEAD zorg，以确保git将其视为路径。

请参阅"Deleting a badly named git branch“中有关双连字符语法( -- )的更多信息。

OP skube添加了in the comments

顺便说一句，他们确实建议放弃工作目录中的更改

(即git checkout -- <file>)。

这似乎与git reset HEAD <file>不一致。

虽然git reset man page清楚地表明了git reset <tree-ish> -- <paths>中缺少树型结构，但对于git checkout -- 来说并非如此。

git checkout <tree-ish> -- <pathspec>

当给定<paths>时，git checkout不切换分支。

从索引文件或命名提交()更新工作树中的命名路径(通常是提交)。

这意味着git checkout -- path将用已暂存(git add'ed)的内容覆盖工作树。

而git reset -- PATH ( git reset的混合形式)将使用HEAD包含的内容重置索引(有效地取消添加的内容)

git reset和git checkout不使用相同的默认值，并且：

• 您可以表示git reset <tree-ish> <file>的默认树：HEAD。

因此，如果不为git checkout提供树，就不能表示默认参数:它是索引。

因此使用git checkout -- file.

在git checkout的情况下必须使用--，因为只有一个参数，并且需要明确该参数代表文件。

注意，git checkout HEAD files是不同的：torek提到了in the comments

git checkout HEAD path从HEAD提交(树型)复制到索引，然后复制到工作目录。

注意:对于2019年8月发布的Git 2.23+，您可能会使用

请参阅the examples

恢复索引中的文件以匹配HEAD中的版本的

(这与使用git-reset相同)

$ git restore --staged hello.c

手册页：

git restore --staged hello.c不指定源，仅恢复索引(--staged)：它(默认情况下)使用HEAD作为源来执行此操作。

默认情况下，工作树和索引的还原源分别为索引和头。

--source可用于将提交指定为恢复源。

其他示例：

您可以同时恢复索引和工作树(这与使用git-checkout相同)

$ git restore --source=HEAD --staged -worktree hello.c

或者是更实用但可读性较差的简短形式：

$ git restore -s@ -SW hello.c

git restore是一个更自然的命令名称，没有歧义。

缺省情况下，git reset等效于git reset HEAD

引用手册页(我的重点)：

git-reset -将当前磁头重置为指定状态。

git重置-q --…git重置(--patch | -p)…合并git重置--软|--混合[-N] |--​|--合并|--保留

在第一种和第二种形式中，将条目从复制到索引。在第三种形式中，将当前的分支标题( head )设置为，可选择修改索引和工作树以匹配。/默认为所有形式的标题。

..。

git重置-q --…​

此表单将所有的索引项重置为其在的状态。(它不会影响工作树或当前分支。)

这意味着git reset <paths> git add <paths>**.**的对立面是

从这里你可以看到，在行为上没有实际的区别。

这看起来更简单，那么为什么会有区别呢？

既然它们都是一样的，那么你也可以使用两者中最短的版本。

第一次，在任何提交之前，头不存在，然后我们得到：

$git reset HEAD stagedFile
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree