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 指针到指定的提交，并将暂存区和工作目录中的内容都重置为该提交的内容。这会丢弃自该提交以来在工作目录和暂存区中所做的所有更改。使用这个选项时要格外小心，因为它会丢弃未提交的更改。
示例
-
撤销上一次的提交（但保留更改在暂存区）：
git reset --soft HEAD~1然后，你可以使用
git commit重新提交这些更改，或者使用git commit --amend修改最近的提交。 -
撤销上一次的提交并取消暂存更改（但保留在工作目录中）：
git reset --mixed HEAD~1或者简单地使用
git reset HEAD~1，因为--mixed是默认模式。 -
撤销上一次的提交并丢弃所有更改（在工作目录和暂存区中）：
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>取代，作为更直观和专用的命令。