git status显示修改，git checkout – <file>不会删除它们
我想删除我的工作副本的所有更改。
运行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")
有多个问题可以导致这种行为：
线结束正常化
我也有这些问题。 它归结为git自动将crlf转换为lf。 这通常是由单个文件中的混合行结尾引起的。 该文件在索引中得到了规范化，但是当git再次非规范化它以对照工作树中的文件进行区分时，结果是不同的。
但是，如果你想解决这个问题，你应该禁用core.autocrlf ，将所有行结束符更改为lf，然后再次启用它。 或者，您可以通过执行以下操作完全禁用它：
git config --global core.autocrlf false
而不是core.autocrlf ，你也可以考虑使用.gitattribute文件。 这样，您可以确保使用repo的每个人都使用相同的规范化规则，防止混合行结束进入存储库。
另外考虑设置core.safecrlf警告，如果你想git警告你，当一个不可逆的规范化将被执行。
git manpages这样说：
CRLF转换承受了破坏数据的轻微机会。 autocrlf = true将在提交期间将CRLF转换为LF，并在结帐期间将LF转换为CRLF。 在提交之前包含LF和CRLF混合的文件不能被git重新创build。 对于文本文件，这是正确的做法：它纠正行结束，使得我们在存储库中只有LF行尾。 但是，对于意外分类为文本的二进制文件，转换可能会破坏数据。
不区分大小写的文件系统
在不区分大小写的文件系统上，当存储库中有不同大小的文件名时，git试图同时检出，但是只有一个在文件系统上结束。 当git试图比较第二个，它会比较它到错误的文件。
该解决scheme要么切换到非大小写不敏感的文件系统，但在大多数情况下这是不可行的，或者重命名并提交另一个文件系统上的文件之一。
我在Windows上遇到这个问题，但没有准备好研究使用config --global core.autocrlf false的后果config --global core.autocrlf false我也没有准备放弃其他私人分支和好东西，并从一个新的克隆开始。 我只需要完成一些事情。 现在。
这工作对我来说，你让git完全重写你的工作目录的想法：
git rm --cached -r . git reset --hard
（请注意，运行只是git reset --hard硬是不够好，也不是一个简单的文件在reset前的文件，如在原来的问题的意见中所build议的）
另一个可能适用于人的解决scheme，因为没有任何文本选项适用于我：
- 用一行代替
.gitattributes的内容：* binary。 这告诉git将每个文件视为一个二进制文件，它不能做任何事情。 - 检查有问题的文件的消息已经消失; 如果不是，你可以
git checkout -- <files>把它们还原到版本库 -
git checkout -- .gitattributes将.gitattributes文件恢复到初始状态 - 检查文件是否仍未标记为已更改。
对于将来有这个问题的人：文件模式更改也可能具有相同的症状。 git config core.filemode false会解决它。
这一直使我疯狂，特别是我不能解决这个问题，没有在网上find任何解决scheme。 这是我如何解决它。 因为这是一个同事的工作，所以不能拿这个学分:)
问题的根源：我最初安装的git没有在Windows上自动换行。 这导致我最初承诺GLFW没有适当的线路结束。
注意：这只是一个本地解决scheme。 克隆回购的下一个人仍然会陷入这个问题。 永久的解决scheme可以在这里find： https ： //help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository 。
安装程序：Xubuntu 12.04 Git与glfw项目的回购
问题：无法重置glfw文件。 无论我尝试了什么，它们总是显示为已修改。
解决了：
edit .gitattributes Comment out the line: # text=auto Save the file restore .gitattributes: git checkout .gitattributes
我有一个相同的问题.bat文件（无法摆脱它在未跟踪的文件）。 混帐签出 – 没有工作，也没有在这个页面上的任何build议。 唯一能为我工作的是做：
git stash save --keep-index
然后删除存储：
git stash drop
我只能通过临时删除我的repo的.gitattributes文件（它定义了* text=auto和*.c text ）来解决这个问题。
删除后我运行git status ，修改没有了。 即使在.gitattribute被放回原位后，他们也没有回来。
有两次相同的问题！ 两次，当存储我做了一些改变，然后试图popup他们回来。 不能popup更改，因为我有很多文件被更改 – 但他们不是！ 他们是完全一样的。
我现在认为我已经尝试了所有上述解决scheme而没有成功。 试过之后
git rm --cached -r . git reset --hard
我现在几乎已经修改了我的存储库中的所有文件。
在分析文件时，它说我已经删除了所有行，然后再添加它们。
有点令人不安。 我现在可以躲避未来
唯一的解决办法是克隆一个新的存储库并重新开始。 （最后一次）
一致的行结束是一件好事。 例如，它不会触发不必要的合并，虽然微不足道。 我已经看到Visual Studio创build混合行尾的文件。
还有一些像bash（在linux上）的程序要求.sh文件是LF终止的。
为了确保这一点，你可以使用gitattributes。 无论autcrlf的值是什么，它都可以在存储库级别上运行。
例如，你可以有这样的.gitattributes：* text = auto
你也可以更具体的每个文件types/扩展名，如果它在你的情况很重要。
然后autocrlf可以在本地为Windows程序转换行结束符。
在混合的C＃/ C ++ / Java / Ruby / R中，Windows / Linux项目运行良好。 目前没有问题。
我也有同样的症状，但一直是由不同的事情引起的。
我无法：
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并再次执行git status时，仍然显示“未跟踪”文件。
经过与同事的几次尝试，我们发现，它是由Grunt引起的！
当Grunt已经被打开，并且因为app.js已经从其他js文件中产生，我们发现在每次使用js文件（也是这个app.js）的操作之后，grunt再次重新创buildapp.js。
这里有很多解决办法，我也许应该在尝试一些方法之前尝试一下。 无论如何，这里还有一个…
我们的问题是，我们没有执行endlines和存储库有DOS / Unix的混合。 更糟糕的是，这实际上是一个开源的回购，在这个位置，我们已经分叉。 这个决定是由那些主要拥有操作系统资源库的人把所有的端口改为Unix，并且提交包括一个.gitattributes来强制执行结束。
不幸的是，这似乎引起了很多像这里描述的问题，一旦DOS-2-Unix之前的代码合并完成，文件将永远被标记为已更改并且不能被恢复。
在我的研究过程中，我碰到了 – https://help.github.com/articles/dealing-with-line-endings/ – 如果我再次面对这个问题，我会先尝试一下。
这是我做的：
-
我最初做了一个合并，才意识到我有这个问题，不得不中止 –
git reset --hard HEAD（ 我碰到一个合并冲突，我怎么能中止合并？ ） -
我在VIM中打开了有问题的文件，并将其更改为Unix（
:set ff=unix）。 像dos2unix这样的工具可以用来代替当然 -
提交
-
合并成
master（master有DOS-2-Unix的变化）git checkout old-code-branch; git merge master -
解决冲突和文件是DOS的，所以不得不
:set ff=unix在VIM中:set ff=unix。 （注意我已经安装了https://github.com/itchynylightlight.vim ，这使我能够看到VIM状态行上的文件格式） - 承诺。 全部sorting！
在Linux计算机上使用repo的贡献者，或者使用Cygwin和文件权限更改的窗口时，也会发生此问题。 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
如果您克隆存储库并立即看到挂起的更改，那么存储库处于不一致的状态。 请不要在.gitattributes文件中注释掉* text=auto 。 这是因为存储库的所有者希望所有文件都与LF行结尾一致存储。
正如HankCa所述，遵循https://help.github.com/articles/dealing-with-line-endings/上的说明是解决问题的方法。; 简单的button：
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
然后合并（或拉请求）分支到回购的所有者。
我碰到的问题是，Windows不关心文件名大小写，但混帐。 所以git存储了一个较低和大写的文件版本，但只能签出一个。
