为什么“git reset HEAD”不会撤消我未提交的、未暂存的更改？

Question

我之前可以通过执行“丢弃”功能通过 SourceTree 撤消更改，该功能在后台会生成以下命令：

git -c diff.mnemonicprefix=false -c core.quotepath=false reset -q HEAD -- myproj.csproj 
git -c diff.mnemonicprefix=false -c core.quotepath=false checkout HEAD -- myproj.csproj

突然这不起作用。我做了丢弃，没有发生错误，重新释放视图，但文件仍然“修改”。然后我尝试在命令行中执行相同的操作，结果相同：

c:\myproject> git reset HEAD

Unstaged changes after reset:
M       myproj.csproj

为什么仍将其列为非分阶段更改？

我已验证该文件确实是可写的（没有进程持有锁）

更新

git checkout 也不起作用：

C:\myproject>git checkout myproj.csproj

C:\myproject>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:   myproj.csproj
#
no changes added to commit (use "git add" and/or "git commit -a")

更新 2 也试过了：

• git checkout --
• git checkout -- .
• git checkout HEAD

，没有一个能解决我的问题

更新 3 - 更进一步：

结果是，当我进行结帐时，.csproj 确实恢复到正确的版本，但是签出的版本使用不同的 换行编码。签入版本具有用于换行的 CR-LF (0D-0A)，而签出版本只有 LF (0A)。因此 git 认为文件在每一行上都是不同的。为什么会这样？

更新 4： 添加了 SourceTree 发出的第二行 git 命令。我第一次没有注意到，这就是为什么我认为git reset HEAD 会做任何事情。这并没有改变根本问题仍然与 CR/LF 相关的事实（我认为）

总结 我从来没有找到解决这个问题的方法，但我通过签入文件“解决了”它。我最初的问题没有包含 SourceTree 确实发出了正确的命令来回滚我想要的信息，所以这里的大多数答案都解决了这个问题。 真正的问题仍不清楚，但我的主要理论是它与 CR/LF 相关。

Answer 1

我刚刚陷入这种情况，唯一能解决的问题是：

git log

在 repo 中找到第一个提交并获取哈希（在我的例子中是从 fdb14f 开始的）

注意：这仅适用于存在问题的存储库位于 Linux 服务器上，而我的 Windows 机器上有一个远程存储库“来源”，其中包含修复 CRLF 问题的最新提交.

git reset --hard fdb14f
git pull origin master

在尝试了各种不同的事情之后，这最终让我解决了这个问题。我在最近的提交中修复了 CRLF 问题，但我尝试过的任何其他方法都无法让我绕过这些文件。

Answer 2

我遇到了类似的事情。我的设置是在 Web 服务器上使用 git 来获取最新的代码。不知什么原因，遇到了这个问题。

# git reset HEAD —hard

重置后未暂存的更改：

 'File Name'

我在这里尝试了所有建议的东西。没有人修复它。

我在这种情况下通过这样做来解决它

git add 'File Name'

那么，

git reset --hard HEAD

这为我解决了问题。

Answer 3

我怀疑您在存储库中保存了带有 CRLF 行结尾的文件，然后在某个地方更改了配置，以便 git 开始规范化行尾字符（core.autocrlf 设置为 true，或者.gitAttributes 文件已添加或更改）。当我遇到这个问题时，原来包含 * text=auto 的 .gitAttributes 文件已添加到我的仓库中。

（EOL 规范化意味着 git 会将行尾字符作为 LF 写入其数据库中，无论您在工作副本中使用什么）。

启用后，Git 不会自动检查您的文件是否需要 EOL 规范化。你必须明确告诉它检查你的所有文件，否则你最终会陷入这种情况：你的存储库中的文件仍然有 CRLF 行结尾，而 git 只会在它接触每个文件时才注意到它应该对它们进行规范化。因此，下次您对文件进行一些更改时，git 会将文件以 LF 行结尾写入其数据库。

当git通过读取操作接触文件时会出现问题。假设您对具有 CRLF 行结尾的文件进行了更改，然后尝试放弃您的更改。 Git 将从其数据库中读取干净的副本，查看它是否有 CRLF 行结尾，然后将文件标记为已修改。该文件实际上并未被修改，但 git 表示它想将 EOL 字符的更改写入其数据库。每次您尝试放弃更改、签出该文件甚至进行硬重置时，都会发生这种情况。这就是为什么似乎无法撤消这些修改的原因。

您应该让 git 对所有文本文件的行尾进行规范化，这样这个问题就不会继续出现（有关如何执行此操作的说明，请参阅 https://stackoverflow.com/a/4683783/1369）。如果可能的话，您甚至可能想要修改您的历史记录，以便在更改 .gitAttributes 设置的同时对行尾进行规范化。

如果您无法修改历史记录，那么您可能会遇到需要检查仍然具有 CRLF 行结尾的旧版本文件的情况。您可能会遇到无法丢弃且不想提交的已修改文件列表。在这种情况下，你可以使用这个变通方法让 git 忘记它想要修改这些文件：

1. 查看旧版本
2. 关闭行尾标准化
3. git reset
4. 重新启用行尾标准化

Answer 4

“为什么它仍被列为非分阶段更改？”

因为裸 git reset HEAD 不会对您的工作树做任何事情。它仅将 HEAD 指针重置为您命名的提交（在这种情况下为无操作，因为您命名为 HEAD），并重置索引以匹配新的 HEAD（在这种情况下再次相同 - 所以网络效果基本上只是扔掉你做过的任何git add、git rm等命令）。

Answer 5

你想要的是 git reset HEAD --hard。 git reset HEAD 仅取消阶段更改。

我建议你也看看 how git can be set to auto convert/deconvert line endings because on projects with multiple developers working on different platforms this will cause anger when a single edit on a file causes git blame to show you as having changed the whole file.

Answer 6

如果您需要删除本地更改，请运行以下命令

git checkout -- file_name

git reset HEAD 不会删除本地更改。