python - git reset --hard HEAD 与 git checkout

Question

我有一个文件 foo.py。我对工作目录做了一些更改，但尚未暂存或提交任何更改。我知道我可以使用 git checkout foo.py 来摆脱这些变化。我还阅读了有关使用 git reset --hard HEAD 的信息，它实质上会重置您的工作目录、暂存区和提交历史记录以匹配最新的提交。

在我的情况下，我的更改仍在工作目录中，是否有任何理由更喜欢使用其中一个？

Answer 1

Is there any reason to prefer using one over the other in my case, where my changes are still in working directory?

不，因为他们会完成同样的事情。

Is there any reason to prefer using [git checkout -- path/to/file] over [git reset --hard] in [general but not in my specific case]?

是的:这只会影响一个文件。如果你的习惯是git reset --hard撤消对一个文件的更改，并且您对其他 文件也有工作树和/或暂存更改，并且您 git reset --hard ，如果不手动重建这些更改，您可能会很不走运。

注意还有第三个结构:git checkout HEAD path/to/file .这个和没有HEAD的区别(用 -- 而不是 ¹)是 用 HEAD意味着首先将永久的、不可更改的提交中的文件版本复制到索引/暂存区，然后再复制到工作树。带有 -- 的那个表示将索引/暂存区中的文件版本复制到工作树中。

---

¹使用--的原因是为了确保 Git 永远不会将文件名与其他任何东西混淆，比如分支名称。例如，假设您将文件命名为 master ，只是为了固执。那么，git checkout master 是做什么的？意思是？是否应该检查分支 master ，或提取文件 master ？ --在git checkout -- master让 Git 和人类清楚地知道这意味着“提取文件 master”。

---

总结，或者，要记住的事情

在任何时候，每个文件都有三个事件副本:

• HEAD 中的一个;
• 索引/暂存区中的一个；
• 工作树中的一个。

git status命令查看所有三个，比较 HEAD -vs-index 首先——这为 Git 提供“要提交的更改”列表——然后是 index-vs-work-tree 第二。第二个为 Git 提供“未暂存提交的更改”列表。

git add命令从工作树复制到索引中。

git checkout命令从 HEAD 复制到索引然后是工作树，或者只是从索引到工作树。所以有点复杂，有多种操作方式:

• git checkout -- <em>path/to/file</em> :从索引复制到工作树。 HEAD 里有什么这里无所谓。 --通常是可选的，除非文件名看起来像分支名称(例如，名为 master 的文件)或选项(例如，名为 -f 的文件)。

• git checkout HEAD -- <em>path/to/file</em> :来自 HEAD 的副本提交，索引，然后工作树。 HEAD 里有什么覆盖索引中的内容，然后覆盖工作树中的内容。 --通常是可选的，除非文件名看起来像一个选项(例如 -f )。

  明智的做法是使用 --永远，就像一个好习惯。

git reset命令复杂(有多种操作方式)。

(这并不是说 git checkout 很简单:它也有很多操作模式，可能太多了。但我认为 git reset 至少要差一点。)