似乎无法丢弃 Git 中的更改答案

【问题标题】：Can't seem to discard changes in Git似乎无法丢弃 Git 中的更改
【发布时间】：2010-12-07 05:39:46
【问题描述】：

从命令行看到以下内容后：

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm

我正在尝试通过键入以下命令来放弃我的更改：

git checkout -- index.htm

但是当我重新运行 git status 时，它看起来完全一样。结帐似乎不起作用。难道我做错了什么？我在 windows/cygwin 上使用 GIT 1.6.1.2。

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm

【问题讨论】：

git checkout HEAD -- index.htm（从上次提交的状态签出，而不是从索引中签出）是否有效？
git checkout HEAD -- index.htm 为我工作！
stackoverflow.com/questions/2016404/…

标签： git revert

【解决方案1】：

这一直困扰着我，几乎我检查的每个 repo 都有我无法丢弃的更改。长话短说，我尝试了以上所有方法，但没有任何效果。这就是我为使事情恢复正常所做的事情（在 Mac 上）：

Completely remove the autocrlf & safecrlf settings from ~/.gitconfig
Completely remove the autocrlf & safecrlf settings from your repo's local config ./.git/config
git rm --cached -r .
git reset --hard

【讨论】：

在尝试了以上所有方法之后，这是唯一对我有用的东西（在 Windows 上）
谢谢！正如安德斯所说，这个解决方案也对我有用。我将 autocrlf 替换为 # autocrlf
到目前为止，唯一能让它在 Windows 上运行的方法。谢谢

【解决方案2】：

这是我的经验，在.git/config中设置以下变量：

[core]
    autocrlf = false
    safecrlf = false
    eol = crlf

然后运行$ git checkout HEAD .，它就可以工作了。但是$ git checkout -- . 不，奇怪！

* git 版本 1.9.3

【讨论】：

【解决方案3】：

git diff 在文件中显示了哪些变化？在 Windows 上，我看到了导致此类问题的行尾问题。在这种情况下，请查看 git config core.autocrlf 和 git config core.safecrlf 的设置。有一些documentation for these settings here。

我会说，如果您使用 git svn 与 subversion 集成，请确保关闭 autocrlf。据我所知，它只是在这个配置中被破坏了，当您完成checkout 以恢复任何更改时，它使大多数工具认为文件已更改。

如果您在执行git checkout 时看到问题，然后git status 显示文件仍在修改，git diff 显示文件在文件的每一行都被修改，那么这就是您的问题正在看。

core.autocrlf

如果为真，则让 git 将文本文件行尾的 CRLF 转换为 LF 从文件系统读取时，以及写入时反向转换文件系统。变量可以设置为输入，在这种情况下转换仅在从文件系统，但文件被写出 LF 在行尾。目前，考虑哪些路径 “文本”（即受到 autocrlf 机制）是纯粹决定的根据内容。

core.safecrlf

如果为真，则让 git 检查是否将 CRLF 转换为由 core.autocrlf 是可逆的。 Git 会验证命令是否修改了文件工作树直接或间接地。例如，提交一个文件，然后签出相同的文件文件应该产生原始文件工作树。如果不是这种情况对于当前的设置 core.autocrlf，git 会拒绝文件。变量可以设置为 “警告”，在这种情况下 git 只会警告不可逆的转换但继续操作。 ...

【讨论】：

core.autocrlf=true core.safecrlf 尚未设置。对于 Windows，这应该设置为 true 吗？两者有什么区别？
我会说，如果您使用的是 git svn，请将它们都关闭。我添加了更多细节。
我假设他的意思是将其旋转至少 90 度
当我将 core.autocrlf 和 core.safecrlf 都设置为 true 时，我可以通过运行 'git reset --hard HEAD' 丢弃检测到的有问题文件中的更改。
感谢git diff 的建议。我一直在努力寻找不同之处。这不是行尾，大多数答案建议更改行尾格式和配置。但是在运行git diff 时，我意识到文件模式（权限）不同。

【解决方案4】：

我觉得你需要通过-f

来自手册页（man git-checkout，GIT-CHECKOUT(1)）：

-f, --force
即使索引或工作树与 HEAD 不同，也要继续。
这用于丢弃本地更改。

例如，丢弃当前分支上的更改并切换到不同的分支：

git checkout -f master

【讨论】：

将 -f 传递给什么？很高兴使答案完整
@Matt 我的意图不是签出不同的分支。答案来自 2009 年，所以我不记得了，但从问题来看，我想我的意思是通过 -f 结帐—— 就像 git checkout -f -- filename
@hasen 您所拥有的三个 cmets 要求澄清，这就是我添加“例如”的原因。该示例不排除 -f 的其他用途
为我工作。 git checkout -f master 抛出“Already on 'master'”但更改消失了。
也对我有用。我觉得-f 比上面的其他建议更安全

【解决方案5】：

正如@1800-information 所暗示的那样，它可能是行尾，但另一种可能性是差异（阻止您使用 checkout 命令恢复这些文件）是文件模式之一。这就是发生在我身上的事情。在我的 git 版本中，您可以使用

git diff index.htm

它会显示文件模式的变化。但是，即使使用 -f 选项，它仍然不会让您使用 checkout 还原它们。为此使用

git config core.filemode false

或通过添加在文本编辑器中更改 git .config

[核心]

filemode = false

完成此操作后，您可以使用

git reset HEAD index.htm

文件应该会消失。

（我从How do I make git ignore mode changes (chmod)? 和updating-file-permissions-only-in-git 的答案中得到了所有这些信息）

【讨论】：

非常感谢！其他任何建议都没有帮助我摆脱文件模式更改。

【解决方案6】：

您使用的是 OSX 还是 Windows？如果是这样，问题可能是有两个同名的文件，但大小写不同。例如。 index.htm 和 Index.htm

Windows 和默认情况下 OSX 使用不区分大小写的文件系统，这与区分大小写的 git 冲突。

【讨论】：

【解决方案7】：

我遇到了这个问题，在尝试了以上所有方法后，没有任何效果。

对我有用的是删除文件所在的目录，然后删除git status 并确保该目录中的所有文件现在都标记为已删除。之后我只是做了git checkout -f，一切都恢复正常了。

【讨论】：

【解决方案8】：

我遇到了同样的问题，上面的 cmets 没有任何效果。事实证明，我的文件系统不区分大小写（osx 默认，但 windows 的行为可能相同），并且在同一目录中存在大写和小写的文件，具有不同的内容。由于在我的计算机上，两个名称都指向同一个文件，所以 git status 总是显示修改，无论我做什么。解决问题：

我不得不从另一台计算机上删除其中一个文件并将其推送到 repo
完全删除整个本地版本
从头开始做 git clone

【讨论】：

【解决方案9】：

我的问题在这里有点相似，我刚刚发现 git 正在跟踪文件权限的更改。我尝试丢弃并重置分支，但文件仍然存在。运行git config --get --local core.filemode，如果为真则需要设置为假以关闭文件权限跟踪。运行git config --local core.fileMode false 应该可以解决它。你可以阅读更多here

【讨论】：

【解决方案10】：

我遇到过类似的问题，它不允许我丢弃不存在或已更改的文件。我在工作中使用 Visual Studio，发现在应用运行时切换分支时会发生这种情况。

git checkout 并试图丢弃并没有帮助。它不起作用，或者它只会告诉我我没有权限。

有效的解决方案：

进入安全模式
丢弃文件

重新启动很痛苦，但这比尝试 100 次要快。

【讨论】：

【解决方案11】：

有一个简单的解决方案。如果发生这种情况（通常来自意外的 Windows 关闭或内存转储）并且您无法丢弃更改甚至在分支之间切换（Git 说您没有足够的权限）；在文件夹选项中的Windows 环境show all hidden files and folders 中。转到您的 GIT 目录（应以 .git 开头）并删除 "index.lock" 文件。那么 Git 应该让你为所欲为。

【讨论】：

【解决方案12】：

我最终做了一个git stash，然后是一个git stash clean 来摆脱一些。在 .git/ 或 ~/.git 中没有看到任何自动 cr/lf 配置。

【讨论】：

【解决方案13】：

就我而言，我无法丢弃与目录相关的更改。例如当我运行 git diff 时，我会看到： -Subproject commit fdcccccccccccccccccccccccccccccccccccccc +Subproject commit f1bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

所以我调用了那个目录并在其中运行了一个 git status。它处于 HEAD 分离状态。然后我在里面运行了git checkout master。这对我来说是正确的。但这对于此处询问的确切场景没有帮助。

【讨论】：

【解决方案14】：

这是一个老问题，但仍然与我相关。直到在办公室四处询问，我才找到答案，发现问题出在子模块上。当它们被更新并且您自己的存储库没有反映这些更改时，它会显示为存在差异，重置头部没有帮助。如果是这种情况，请运行：

git status update

应该帮助解决问题（在这种特殊情况下）

【讨论】：

【解决方案15】：

我在Android Studio 上进行libGDX 项目，我想放弃我所做的所有更改，但没有任何对我有用，我想出的解决方案是将所有更改提交到新分支

git checkout -b TRASH
git add .
git commit -m "discarded changes"
git checkout master

然后您可以根据需要删除TRASH 分支。

【讨论】：

【解决方案16】：

我在 Windows 中遇到权限问题，必须执行 icacls containingFolder /reset /t /l /c，然后双击该文件夹以恢复我的权限。

【讨论】：

【解决方案17】：

我的 .gitattributes 包含以下内容：

* text=auto eol=lf

要解决此问题，请编辑 .gitattributes 以删除此行，该行放宽行尾。然后git reset --hard HEAD 还原了文件和.gitattributes 文件。

【讨论】：

【解决方案18】：

对我来说，这个问题与下载通过 Netlify CMS 上传的 Git-LFS 图像相结合，并由他们的 Netlify 大型媒体处理程序提供不同的服务。

我的解决方案是从我的~/.gitconfig 中注释/删除这些行，使其如下所示，然后再次检查git status。

# [filter "lfs"]
#   clean = git-lfs clean %f
#   smudge = git-lfs smudge %f
#   required = true

或者您可以通过在 repo 根目录中的 .gitconfig 添加更多本地过滤器，并以某种方式覆盖那里的 lfs 过滤器规则。

希望这可以帮助一个人。

【讨论】：

【解决方案19】：

其中许多答案解决了许多问题之一。因此，您可能必须尝试一些，直到找到问题所在。所以，我会加入我自己的经验。

就我而言，问题是我的~/.gitconfig 中有一个全局~/.gitattributes 文件。当我最终检查该文件时，我能够找到有问题的扩展名并手动纠正它。

特别是对于我正在处理的有问题的回购，*.bat 需要是 -text eol=crlf 而不是 text eol=crlf。

【讨论】：

【解决方案20】：

遇到了同样的问题，我有 core.autocrlf=false 配置。

原来我遇到的问题是我在那里添加了* text eol=lf 到.gitattibutes 文件，并将其提交到repo，而没有在所有现有文件中将CRLF 转换为LF。因此，即使在 repo 的另一个新克隆中，这些文件也会显示为已修改。 git status 报告文件被修改有点奇怪，即使它们在 git 工作目录和舞台区域中具有相同的 CRLF。在我看来，modified 意味着如果文件被添加并提交，将会有一些基于当前配置的非空更改。

于是我git add把所有文件都提交了（确认提交包括CRLF->LF的转换），再也没有得到修改文件报告。

【讨论】：

【解决方案21】：

我也遇到了类似的问题，以下步骤帮助了我：

git commit -am 'temp commit'
git pull origin master
git reset head~1
git reset head --hard

希望它也能帮助其他人。

【讨论】：