Git 版本控制--git restore和git reset

git restore 和 git reset 是 Git 版本控制系统中两个用于撤销更改的命令，但它们的作用范围和用途有所不同。

git restore

git restore 是 Git 版本控制系统中的一个命令，用于撤销工作目录中的更改，但不影响暂存区（staging area）或历史记录。这个命令是在 Git 2.23 版本中引入的，旨在提供一个更直观和直接的方式来恢复文件到之前的状态，替代了之前可能需要结合使用 git checkout -- <file> 或 git reset HEAD <file> 命令的场景。

基本用法

• 恢复特定文件：如果你在工作目录中修改了一个或多个文件，并希望撤销这些更改，可以使用 git restore 命令后跟文件名。例如，要恢复 file.txt 文件到其最近的提交状态，你可以运行：

  git restore file.txt

• 恢复多个文件：你可以一次性恢复多个文件，只需在命令中列出它们，用空格分隔。

• 恢复整个目录：如果你修改了一个目录中的所有文件，并希望恢复整个目录到之前的提交状态，只需指定目录名即可。注意，这不会递归地恢复子目录中的文件，除非明确指定。

• 使用 --staged 选项：默认情况下，git restore 恢复的是工作目录中的文件。但是，如果你希望从暂存区（即你即将提交的更改）中移除一个或多个文件，可以使用 --staged 选项。这相当于使用 git reset HEAD <file>，但不会更改工作目录中的文件。

  git restore --staged file.txt

  注意事项

• 使用 git restore 时，确保你了解哪些更改将被撤销，特别是当处理重要文件时。
• 如果你已经提交了你的更改，git restore 将不会撤销这些更改。在这种情况下，你可能需要使用 git revert 或 git reset 等命令来撤销提交。
• git restore 是一个相对较新的命令，因此请确保你的 Git 版本支持它。如果你的 Git 版本较旧，你可能需要使用 git checkout 或 git reset 命令的等效用法

git reset

基本用法

git reset 有三个主要模式，通过 --soft、--mixed（默认）和 --hard 选项来指定：

• --soft：仅移动 HEAD 指针到指定的提交，保留暂存区和工作目录中的所有更改。这意呀着所有更改仍然被标记为已暂存（staged），准备好被提交。这通常用于重新组织提交历史，而不改变文件在暂存区和工作目录中的状态。

• --mixed（或没有指定模式）：移动 HEAD 指针到指定的提交，并将暂存区的内容重置为该提交的内容，但保留工作目录中的更改。这相当于撤销了之前的 git add 命令，使得之前已暂存的更改变为未暂存状态。

• --hard：移动 HEAD 指针到指定的提交，并将暂存区和工作目录中的内容都重置为该提交的内容。这会丢弃自该提交以来在工作目录和暂存区中所做的所有更改。使用这个选项时要格外小心，因为它会丢弃未提交的更改。

示例

1. 撤销上一次的提交（但保留更改在暂存区）：

   git reset --soft HEAD~1

   然后，你可以使用 git commit 重新提交这些更改，或者使用 git commit --amend 修改最近的提交。

2. 撤销上一次的提交并取消暂存更改（但保留在工作目录中）：

   git reset --mixed HEAD~1

   或者简单地使用 git reset HEAD~1，因为 --mixed 是默认模式。

3. 撤销上一次的提交并丢弃所有更改（在工作目录和暂存区中）：

   git reset --hard HEAD~1

   警告：这将永久丢弃自上一次提交以来所做的所有更改。

注意事项

• 在使用 git reset --hard 之前，请确保你确实想要丢弃这些更改，因为它们将无法恢复（除非你有其他备份或未推送的引用）。
• git reset 默认不会更改工作目录中的文件，除非你使用了 --hard 选项。
• 如果你只是想将某些文件从暂存区中移除，但不更改 HEAD 指针或工作目录中的文件，你可以使用 git restore --staged <file>（Git 2.23+）或 git reset HEAD <file>（在较旧的 Git 版本中）。然而，请注意 git reset HEAD <file> 在新版本的 Git 中已被 git restore --staged <file> 取代，作为更直观和专用的命令。