git status 显示修改，git checkout --;不删除它们

Question

我想删除对我的工作副本的所有更改。
运行 git status 显示已修改的文件。
我所做的一切似乎都无法删除这些修改。
例如：

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

Answer 1

我在 Windows 上遇到了这个问题，但不准备研究使用 config --global core.autocrlf false 的后果，我也不准备放弃我的存储中的其他私有分支和好东西并从一个新的克隆开始。我只需要完成一些事情。现在。

这对我有用，因为你让 git 完全重写你的工作目录：（

git rm --cached -r .
git reset --hard

请注意，仅运行 git reset --hard 还不够好，也不是简单的 rm code> 在重置之前的文件上，如原始问题的评论中所建议的那样）

Answer 2

有多种问题可能导致此行为：

行结束规范化

我也遇到过此类问题。归结为 git 自动将 crlf 转换为 lf。这通常是由单个文件中的混合行结尾引起的。该文件在索引中被规范化，但是当 git 再次对其进行非规范化以将其与工作树中的文件进行比较时，结果是不同的。

但如果你想解决这个问题，你应该禁用 core.autocrlf，将所有行结尾更改为 lf，然后再次启用它。或者您可以通过以下方式完全禁用它：

git config --global core.autocrlf false

您还可以考虑使用 而不是 core.autocrlf .gitattributes 文件。这样，您可以确保使用存储库的每个人都使用相同的规范化规则，从而防止混合行结尾进入存储库。

如果您希望 git 在执行不可逆标准化时发出警告，还可以考虑设置 core.safecrlf 来发出警告。

git 手册页这样说：

CRLF 转换的可能性很小
损坏数据。 autocrlf=true 将
在提交期间将 CRLF 转换为 LF 并
结账时从 LF 变为 CRLF。一个文件
包含 LF 和 CRLF 的混合
提交之前无法重新创建
通过 git。对于文本文件，这是
正确的做法：纠正线路
结尾使得我们只有 LF 行
存储库中的结尾。但对于
意外的二进制文件
分类为文本转换可以
损坏的数据。

不区分大小写的文件系统

在不区分大小写的文件系统上，当存储库中存在具有不同大小写的相同文件名时，git 会尝试检出这两个文件，但最终只有一个文件出现在文件系统上。当 git 尝试比较第二个文件时，它会将其与错误的文件进行比较。

解决方案要么切换到不区分大小写的文件系统，但这在大多数情况下是不可行的，要么重命名并提交另一个文件系统上的文件之一。

Answer 3

另一个可能对人们有用的解决方案，因为没有一个文本选项对我有用：

1. 将 .gitattributes 的内容替换为一行：* binary。这告诉 git 将每个文件视为它无法执行任何操作的二进制文件。
2. 检查有问题的文件的消息是否已消失；如果不是，您可以 git checkout -- 将它们恢复到存储库版本
3. git checkout -- .gitattributes 以恢复 .gitattributes code> 文件恢复到其初始状态
4. 检查文件是否仍未标记为已更改。

Answer 4

对于未来遇到此问题的人：更改文件模式也可能会出现相同的症状。 git config core.filemode false 将修复它。

Answer 5

这让我发疯，尤其是如果没有网上找到的任何解决方案，我就无法解决这个问题。这是我解决问题的方法。不能在这里获得学分，因为这是同事的工作:)

问题根源：我最初安装的 git 在 Windows 上没有自动行转换。这导致我最初对 GLFW 的承诺没有正确的行结尾。

注意：这只是本地解决方案。下一个克隆存储库的人
仍然会被这个问题困扰。永久解决方案可以是
在这里找到：
https://help.github.com/文章/处理行结尾/#re-normalizing-a-repository。

设置：
Xubuntu 12.04
包含 glfw 项目的 Git 存储库

问题：无法重置 glfw 文件。无论我尝试什么，它们总是显示为已修改。

已解决：

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Answer 6

我有一个具有相同问题的 .bat 文件（无法在未跟踪的文件中删除它）。 git checkout -- 不起作用，此页面上的任何建议也不起作用。唯一对我有用的事情是：

git stash save --keep-index

然后删除存储：

git stash drop

Answer 7

同样的问题遇到两次了！两次我都隐藏了一些更改，然后尝试将它们弹出。无法弹出更改，因为我有很多已更改的文件 - 但它们没有！它们完全一样。

我现在认为我已经尝试了上述所有解决方案但没有成功。在尝试之后，

git rm --cached -r .
git reset --hard

我现在几乎修改了存储库中的所有文件。

比较文件时，它说我已删除所有行，然后再次添加它们。

有点令人不安。我现在将避免将来隐藏。

唯一的解决方案是克隆一个新的存储库并重新开始。 （上次做过）

Answer 8

尝试做一个

git checkout -f

这应该清除当前工作本地存储库中的所有更改

Answer 9

通常，在 GIT 中清除所有修改&新文件，以下 2 个命令应该可以很好地工作（小心，这将删除您可能创建的所有新文件+文件夹，并将所有修改的文件恢复到 的状态）当前提交）：

$ git clean --force -d
$ git checkout -- .

也许有时更好的选择是使用可选消息执行“git stash push”，如下所示：

$ git stash push -m "not sure if i will need this later"

这也会清除所有新文件和修改过的文件，但您将把所有文件都隐藏起来，以防万一你想恢复它们。 GIT 中的存储可以从一个分支转移到另一个分支，因此如果您愿意，您可以将它们恢复到不同的分支中。

附带说明一下，如果您已经暂存了一些新添加的文件并想要删除它们，这应该可以解决问题：

$ git reset --hard

如果以上所有内容都不适合您，请阅读以下内容不久前对我有用的方法：

我之前几次遇到过这个问题。我目前正在我的雇主提供的 Windows 10 机器上进行开发。今天，这种特殊的 git 行为是由我从“开发”分支创建一个新分支引起的。由于某种原因，在我切换回“develop”分支后，一些看似随机的文件仍然存在，并在“git status”中显示为“已修改”。

另外，那时我无法签出另一个分支，所以我被困在我的“开发”分支上。

这就是我所做的：

$ git log

我注意到今天早些时候从“develop”创建的新分支显示在第一个“commit”消息中，在末尾引用“HEAD ->development，origin/develop，origin/HEAD， 我今天早些时候创建的分支”。

因为我并不真正需要它，所以我删除了它：

$ git branch -d The-branch-i-created-earlier-today

更改的文件仍然显示，所以我这样做了：

$ git stash

这解决了我的问题：

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

当然 $ git stash list 将显示隐藏的更改，因为我的存储很少，也不需要任何存储，我执行了 $ git stash clear 来删除所有存储。

注意：我还没有尝试过按照之前有人建议的那样操作：

$ git rm --cached -r .
$ git reset --hard

这可能也有效，下次遇到这个问题时我一定会尝试一下。

Answer 10

我只能通过临时删除存储库的 .gitattributes 文件（定义 * text=auto 和 *.c text）来解决此问题。

删除后我运行了 git status ，修改消失了。即使 .gitattributes 放回原位后，它们也没有返回。

Answer 11

我遇到的问题是 Windows 不关心文件名大小写，但 git 关心。因此 git 存储了文件的小写和大写版本，但只能签出一个。

Answer 12

我有一个较旧的冗余分支，具有不同的行结尾。切换到这个让我有点卡住，直到我应用了一些 --force 。

git checkout mainbranch --force

接下来是一个快速的gitbranch -Dbronchbranch。

Answer 13

具有一致的行结尾是一件好事。例如，它不会触发不必要的合并，尽管这是微不足道的。我见过 Visual Studio 创建具有混合行结尾的文件。

此外，某些程序（例如 bash（在 Linux 上））确实要求 .sh 文件以 LF 结尾。

为了确保发生这种情况，您可以使用 gitattributes。无论 autcrlf 的值是多少，它都在存储库级别上工作。

例如，你可以有这样的 .gitattributes：
* text=auto

如果对您的情况确实重要，您还可以更具体地说明每个文件类型/扩展名。

然后autocrlf可以在本地转换Windows程序的行结尾。

在混合 C#/C++/Java/Ruby/R、Windows/Linux 项目上，此功能运行良好。到目前为止没有问题。

Answer 14

我也有同样的症状，但是由不同的原因引起的。

我无法：

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

即使
git rm --cached app.js 它标记为已删除，并且在未跟踪的文件中我可以看到 app.js。但是当我再次尝试 rm -rf app.js 和 peform git status 时，它仍然显示“未跟踪”中的文件。

经过与同事几次尝试后，我们发现这是由 Grunt 引起的！

由于 Grunt 已打开，并且 app.js 是从其他几个 js 文件生成的，我们发现每次使用 js 文件（也是此 app.js）操作后，grunt 都会重新创建 app。又是js。

Answer 15

当存储库的贡献者在 Linux 计算机上工作或使用 Cygwin 且文件权限发生更改的 Windows 时，也可能会出现此问题。 Git 只知道 755 和 644。

此问题的示例以及如何检查它：

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

为了避免这种情况，您应该确保使用正确设置 git

git config --global core.filemode false

Answer 16

这里有很多解决方案，在我想出自己的解决方案之前，我也许应该尝试其中的一些。不管怎样，还有一个……

我们的问题是我们没有强制执行endlines，并且存储库混合了DOS / Unix。更糟糕的是，它实际上是一个处于这个位置的开源存储库，并且我们已经分叉了。那些拥有操作系统存储库主要所有权的人决定将所有行尾更改为 Unix，并且提交了包含 .gitattributes 的内容来强制行尾。

不幸的是，这似乎会导致类似于此处描述的问题，一旦完成 DOS-2-Unix 之前的代码合并，文件将永远被标记为已更改并且无法恢复。

在我对此的研究过程中，我遇到了 - https://help .github.com/articles/dealing-with-line-endings/ - 如果我再次遇到这个问题，我会首先尝试一下。

---

这是我所做的：

1. 我' d 最初进行了合并，然后意识到我遇到了这个问题，不得不中止 - git reset --hard HEAD (我遇到了合并冲突。我怎样才能中止合并？）

2. 我在VIM 并更改为 Unix (:set ff=unix)。可以使用像dos2unix这样的工具来代替

3. commited

4. 合并master（master有DOS-2-Unix）更改）

   git checkout 旧代码分支；
git merge master

5. 解决了冲突，文件再次变为 DOS，因此在 VIM 中时必须 :set ff=unix 。 （注意我已经安装了 https://github.com/itchyny/lightline.vim ，它允许我查看 VIM 状态行上的文件格式是什么）

6. 已提交。都整理好了！

Answer 17

我提交了所有更改，然后执行并撤消了提交。
这对我有用

git add 。

git commit -m“随机提交”

git reset --hard HEAD~1

Answer 18

如果您克隆存储库并立即看到待处理的更改，则该存储库处于不一致状态。请不要从 .gitattributes 文件中注释掉 * text=auto 。这是专门放在那里的，因为存储库的所有者希望所有文件都以 LF 行结尾一致地存储。

正如 HankCa 所说，按照 https://help.github 上的说明进行操作。 com/articles/dealing-with-line-endings/ 是解决问题的方法。简单按钮：

git clone git@host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git push
git push -u origin normalize-line-endings

然后将分支合并（或拉取请求）到存储库的所有者。

Answer 19

此页面上的其他内容均不起作用。这终于对我有用了。显示没有未跟踪或已提交的文件。

git add -A
git reset --hard

Answer 20

对我来说，问题是在执行命令

git checkout

时打开了 Visual Studio关闭 Visual Studio 后，该命令起作用了，我终于可以从堆栈中应用我的工作。因此，请检查所有可能更改代码的应用程序，例如 SourceTree、SmartGit、NotePad、NotePad++ 和其他编辑器。

Answer 21

我们公司也面临着类似的情况。所提出的方法都没有对我们有帮助。研究的结果是，问题暴露了。 问题是，Git 中有两个文件，它们的名称仅在符号寄存器上有所不同。 Unix 系统将它们视为两个不同的文件，但 Windows 简直要疯了。 为了解决这个问题，我们删除了服务器上的其中一个文件。之后，在 Windows 上的本地存储库中帮助执行接下来的几个命令（以不同的顺序）：

git reset --hard
git pull origin
git merge

Answer 22

我通过编辑 .git/config 解决了这个问题，添加：

[branch "name_branch"]
    remote = origin
    merge = refs/heads/name_branch

然后我去了 .git/refs/heads/name_branch
并放置最后一次提交的 ID在此处输入代码

Answer 23

我这样解决了这个问题：

1. 复制所需的正确代码的内容
2. 从磁盘中删除导致问题的文件（无法恢复的文件）。现在您应该会发现同一文件的两个版本都标记为已删除。
3. 提交文件删除。
4. 使用相同的名称再次创建文件，并粘贴您在步骤 1 中复制的正确代码，
5. 提交新文件的创建。

---

这对我有用。

Answer 24

这里提出的一个解决方案不起作用，我发现该文件实际上是一些特殊字符的链接：

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''
\211''PNG'
\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png

Answer 25

.gitattributes 与

test_file_with_crlf text eol=crlf 

存储库中实际 CRLF 的文件不太吻合（可能使用 core.autocrlf=false 签入）

解决方案：

1. 使用 autorcrlf=input 重新添加文件（请参阅 git add
   --renormalize）
2. 在此提交之前尝试不要进行任何操作。