如何从工作目录而不是登台区域重置所有文件？

Question

有没有一种方法可以重置工作目录中的所有文件，而不能重置暂存区中的所有文件？

我知道使用以下命令可以重置任何单个文件：

git checkout thefiletoreset.txt

另外，通过使用以下命令，可以将整个存储库重置为最后的提交状态：

git reset --hard

但是，是否有任何命令可以重置整个工作目录，而使暂存区域保持不变？

Answer 1

你最初的问题对我来说并不完全清楚，但你的评论表明你的意思是：

如何将文件从暂存区复制回工作树？

答案确实是git checkout。您可以提供git checkout各种选项，但默认是读取当前索引/暂存区：

git checkout -- file

file从暂存区中提取 的版本到工作树，无论 的暂存区版本是否file与 的HEAD提交版本匹配file。

正如你所见：

git checkout -- directory

提取路径名以directory/.开头的所有文件。由于.命名当前目录：

git checkout -- .

如果您位于工作树的顶层，则提取索引中存在的所有文件。

（--如果您想要的文件名类似于git checkout选项或分支名称，则需要此处。例如，如果您想要名为masteror的文件-b，git checkout masterorgit checkout -b会混淆git checkout，但git checkout -- -b master会告诉git checkout它-b和master是两个文件的名称，而不是-b master选项。--在这里养成只用自动使用的习惯就好。）

Answer 2

但是，是否有任何命令可以重置整个工作目录，而使暂存区域保持不变？

使用Git 2.23（Q3 2019），是的，有：git restore。

见提交97ed685，提交d16dc42，提交bcba406（二〇一九年六月二十日），提交4e43b7f，提交1235875，提交80f537f，提交fc991b4，提交75f4c7c，提交4df3ec6，提交2f0896e，提交a5e5f39，提交3a733ce，提交e3ddd3b，提交183fb44，提交4058199，commit a6cfb9b，commit be8ed50，commit c9c935f，commit 46e91b6（2019年4月25日）和Nguy？pcloudsnTháiNg ？c Duy（）提交328c6cb（2019年3月29日）。
^{（通过合并JUNIOÇ滨野- gitster-在提交f496b06，2019年7月9日）}

checkout：将其一部分拆分为新命令' restore'

以前，交换分支业务“ git checkout'成为新命令” switch'。这将添加restore用于检出路径path 的命令。

与相似git-switch，添加了一个新的手册页来描述该命令将成为什么。该实现将很快更新以匹配手册页。

与“ git checkout <paths>” 有几个主要区别：

• 'restore' by default will only update worktree.
  This matters more when --source is specified ('checkout <tree> <paths>' updates both worktree and index).

• 'restore --staged' can be used to restore the index.
  This command overlaps with 'git reset <paths>'.

• both worktree and index could also be restored at the same time (from a tree) when both --staged and --worktree are specified. This overlaps with 'git checkout <tree> <paths>'

• default source for restoring worktree and index is the index and HEAD respectively. A different (tree) source could be specified as with --source (*).

• when both index and worktree are restored, --source must be specified since the default source for these two individual targets are different (**)

• --no-overlay is enabled by default, if an entry is missing in the source, restoring means deleting the entry

(*) I originally went with --from instead of --source.
I still think --from is a better name. The short option -f however is already taken by force. And I do think short option is good to have, e.g. to write -s@ or -s@^ instead of --source=HEAD.

(**) If you sit down and think about it, moving worktree's source from the index to HEAD makes sense, but nobody is really thinking it through when they type the commands.

Before Git 2.24 (Q3 2019), "git checkout" and "git restore" can re-populate the index from a tree-ish (typically HEAD), but did not work correctly for a path that was removed and then added again with the intent-to-add (ita or i-t-a) bit, when the corresponding working tree file was empty.
This has been corrected.

See commit 620c09e (01 Aug 2019), and commit ecd7204 (02 Aug 2019) by Varun Naik (varunnaik).
Helped-by: Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 072735e, 22 Aug 2019)}

checkout.c: unstage empty deleted ita files

It is possible to delete a committed file from the index and then add it as intent-to-add.
After git checkout HEAD <pathspec>, the file should be identical in the index and HEAD. The command already works correctly if the file has contents in HEAD. This patch provides the desired behavior even when the file is empty in HEAD.

git checkout HEAD <pathspec> calls tree.c:read_tree_1(), with fn pointing to checkout.c:update_some().
update_some() creates a new cache entry but discards it when its mode and oid match those of the old entry. A cache entry for an ita file and a cache entry for an empty file have the same oid. Therefore, an empty deleted ita file previously passed both of these checks, and the new entry was discarded, so the file remained unchanged in the index.
After this fix, if the file is marked as ita in the cache, then we avoid discarding the new entry and add the new entry to the cache instead.