git - 什么是 `git restore` 命令， `git restore` 和 `git reset` 之间有什么区别？

Question

当我想取消暂存文件时，我所有的 Git 教程都显示如下内容:

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

    renamed:    README.md -> README
    modified:   CONTRIBUTING.md

这个提示告诉我们使用 git reset用于取消暂存文件。
但是，在我的终端中，我看到:

git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    renamed:    cat.js -> catcat.js
    renamed:    tolendo.gogo -> tolendo.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    readme (copy).md
    tolendo (copy).txt
    zing (copy).html

我的终端告诉我使用 git restore --staged但教程，以及 Git’s website ，告诉我用 git reset HEAD .
我不知道新的 restore命令。我试过谷歌找到 git reset 之间的区别和 git restore但似乎没有什么适合我的问题。

Answer 1

我已赠送 git restore (仍被标记为“实验性”)在“How to reset all files from working directory but not from staging area? ”中，以及最近的 Git 2.23(2019 年 8 月)。

它有助于分离 git checkout分成两个命令:

一个用于文件( git restore )，可以覆盖 git reset案件。

一个用于分支( git switch ，如“Confused by git checkout ”所示)，它只处理分支，而不处理文件。

如 reset, restore and revert文件指出:

There are three commands with similar names: git reset, git restore and git revert.

• git-revert is about making a new commit that reverts the changes made by other commits.
• git-restore is about restoring files in the working tree from either the index or another commit.
  This command does not update your branch.
  The command can also be used to restore files in the index from another commit.
• git-reset is about updating your branch, moving the tip in order to add or remove commits from the branch. This operation changes the commit history.
  git reset can also be used to restore the index, overlapping with git restore.

所以:

To restore a file in the index to match the version in HEAD (this is the same as using git-reset)

git restore --staged hello.c

or you can restore both the index and the working tree (this the same as using git-checkout)

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

or the short form which is more practical but less readable:

git restore -s@ -SW hello.c

在 Git 2.25.1(2020 年 2 月)中，“ git restore --staged”没有正确更新缓存树结构，导致之后写入假树，这已得到纠正。

见 discussion .

见 commit e701bab (2020 年 1 月 8 日) 来自 Jeff King ( peff ) .
(由 Junio C Hamano -- gitster -- merge 于 commit 09e393d ，2020 年 1 月 22 日)

restore: invalidate cache-tree when removing entries with --staged

^{Reported-by: Torsten Krah
Signed-off-by: Jeff King}

When "git restore --staged " removes a path that's in the index, it marks the entry with CE_REMOVE, but we don't do anything to invalidate the cache-tree.
In the non-staged case, we end up in checkout_worktree(), which calls remove_marked_cache_entries(). That actually drops the entries from the index, as well as invalidating the cache-tree and untracked-cache.

But with --staged, we never call checkout_worktree(), and the CE_REMOVE entries remain. Interestingly, they are dropped when we write out the index, but that means the resulting index is inconsistent: its cache-tree will not match the actual entries, and running "git commit" immediately after will create the wrong tree.

We can solve this by calling remove_marked_cache_entries() ourselves before writing out the index. Note that we can't just hoist it out of checkout_worktree(); that function needs to iterate over the CE_REMOVE entries (to drop their matching worktree files) before removing them.

One curiosity about the test: without this patch, it actually triggers a BUG() when running git-restore:

BUG: cache-tree.c:810: new1 with flags 0x4420000 should not be in cache-tree

But in the original problem report, which used a similar recipe, git restore actually creates the bogus index (and the commit is created with the wrong tree). I'm not sure why the test here behaves differently than my out-of-suite reproduction, but what's here should catch either symptom (and the fix corrects both cases).

使用 Git 2.27(2020 年第二季度)，“ git restore --staged --worktree” 现在默认从“HEAD”中取出内容 ，而不是犯错。

见 commit 088018e (2020 年 5 月 5 日)来自 Eric Sunshine ( sunshineco ) .
(由 Junio C Hamano -- gitster -- merge 在 commit 4c2941a 中，2020 年 5 月 8 日)

restore: default to HEAD when combining --staged and --worktree

^{Signed-off-by: Eric Sunshine
Reviewed-by: Taylor Blau}

By default, files are restored from the index for --worktree, and from HEAD for --staged.

When --worktree and --staged are combined, --source must be specified to disambiguate the restore source, thus making it cumbersome to restore a file in both the worktree and the index.

(Due to an oversight, the --source requirement, though documented, is not actually enforced.)

However, HEAD is also a reasonable default for --worktree when combined with --staged, so make it the default anytime --staged is used (whether combined with --worktree or not).

所以现在，这有效:

git restore --staged --worktree
git restore -SW