我总是对此感到困惑，所以这里有一个提醒测试用例；假设我们有一个bash脚本来测试git：

set -x
rm -rf test
mkdir test
cd test
git init
git config user.name test
git config user.email test@test.com
echo 1 > a.txt
echo 1 > b.txt
git add *
git commit -m "initial commit"
echo 2 >> b.txt
git add b.txt
git commit -m "second commit"
echo 3 >> b.txt

此时，更改不会在缓存中暂存，因此git状态为：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")

如果从这一点开始，我们执行git结账，结果是：

$ git checkout HEAD -- b.txt
$ git status
On branch master
nothing to commit, working directory clean

如果我们改为git重置，结果是：

$ git reset HEAD -- b.txt
Unstaged changes after reset:
M   b.txt
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")

因此，在这种情况下，如果更改未暂存，git reset不会产生任何影响，而git checkout会覆盖更改。

现在，让我们假设上面脚本的最后一个更改是暂存/缓存的，也就是说我们在最后还做了git add b.txt。

在这种情况下，此时的git状态为：

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

    modified:   b.txt

如果从这一点开始，我们执行git结账，结果是：

$ git checkout HEAD -- b.txt
$ git status
On branch master
nothing to commit, working directory clean

如果我们改为git重置，结果是：

$ git reset HEAD -- b.txt
Unstaged changes after reset:
M   b.txt
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")

因此，在这种情况下-如果更改是暂存的，git reset基本上会将暂存的更改转换为未暂存的更改-而git checkout将完全覆盖更改。

Git 2.23引入了一个还原来实现这一点，我认为，这是为了让这些问题的答案变得简单明了。

git restore [--] <pathspec>...

与往常一样，可能需要--，但当文件名以破折号开头时。（此处不可能与分支名称混淆，因为恢复的范围不包括分支，而不是全部检出）

要完成还原，还可以使用--staged还原暂存文件，并使用--source=<tree>从与HEAD不同的提交还原。

我使用SHA id恢复文件，我所做的是git checkout＜SHA hash id＞＜文件名＞

git还原文件

请参阅此重复答案（确保向下滚动到2020更新）：https://stackoverflow.com/a/31281748/12763497

git checkout a3156ae4913a0226caa62d8627e0e9589b33d04c -p */SearchMaster.jsp

细分：a3156ae4913a0226caa62d8627e0e9589b33d04c=这是提交的哈希值。这是我自己的分支（而不是主分支）。

-p标志是路径。

*/SearchMaster.jsp是文件名。

git checkout <commit> <filename>

我今天使用这个是因为我意识到我的收藏夹在几次提交之前被覆盖了，当我升级到drupal 6.10时，所以我不得不把它拿回来。以下是我所做的：

git checkout 088ecd favicon.ico