有多种问题会导致这种行为:

行结束归一化

我也遇到过这种问题。归根结底是git自动将crlf转换为lf。这通常是由单个文件中混合的行结束符引起的。该文件在索引中得到了规范化，但是当git再次对其进行反规范化以与工作树中的文件进行区分时，结果是不同的。

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

git config --global core.autocrlf false

而不是核心。独裁，你也可以考虑使用.gitattributes文件。通过这种方式，您可以确保使用repo的每个人都使用相同的规范化规则，防止混合的行尾进入存储库。

还要考虑设置核心。如果您希望git在执行不可逆规范化时发出警告，则使用Safecrlf。

git的手册上写着:

CRLF转换有轻微的可能性 破坏数据。autocrlf = true将 在提交和期间将CRLF转换为LF 结帐时LF到CRLF。一个文件 它含有LF和CRLF的混合物 之前无法重新创建提交 git。对于文本文件，这是 正确的做法是:修正直线 这样我们就只有LF线 存储库中的结尾。但对于 二进制文件 分类为文本的转换可以 腐败的数据。

不区分大小写的文件系统

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

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

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

还有一些程序，如bash(在linux上)确实要求.sh文件以LF终止。

为了确保发生这种情况，可以使用gitattributes。不管autcrlf的值是什么，它都在存储库级别上工作。

例如，你可以有这样的.gitattributes: *文本=汽车

如果对您的情况有影响，您还可以更具体地指定每个文件类型/扩展名。

然后，selff可以在本地转换Windows程序的行结束符。

在c# / c++ /Java/Ruby/R, Windows/Linux的混合项目中，这种方法运行良好。目前还没有问题。

对于将来遇到此问题的人:文件模式更改也可能有相同的症状。Git配置核心。Filemode false将修复它。

这快把我逼疯了，尤其是没有网上找到的任何解决方案，我都无法解决这个问题。下面是我的解决方法。因为这是一个同事的作品，所以不能在这里获得学分:)

问题的来源:我最初安装的git在windows上没有自动行转换。这导致我最初提交到GLFW没有适当的行结束。

注意:这只是一个本地解决方案。下一个克隆回购的人 仍然会被这个问题困住。一个永久的解决办法是 在这里找到: 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

我只能通过临时删除我的repo的.gitattributes文件来修复这个问题(其中定义了* text=auto和*.c text)。

删除后我运行git状态，修改消失了。即使在.gitattributes被放回原处之后，它们也没有返回。

我在Windows上遇到了这个问题，但还没有准备好研究使用配置全局核心的后果。我也不准备放弃我的其他私人分支和好东西，开始一个新的克隆。我只是需要做点事。现在。

这对我来说是可行的，因为你让git完全重写你的工作目录:

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

(请注意，仅仅运行git reset -hard不够好，在重置之前对文件进行简单的rm也不够好，就像对原始问题的评论中建议的那样)

我有一个.bat文件有同样的问题(无法摆脱它，它在未跟踪的文件)。Git签出—不起作用，本页上的任何建议也不起作用。唯一对我有用的是:

git stash save --keep-index

然后删除存储:

git stash drop

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

我没能:

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

即使在 git rm——缓存app.js，它的签名为删除，在未跟踪的文件中，我可以看到app.js。但是当我尝试rm -rf app.js并再次执行git状态时，它仍然显示我的文件处于“untracked”状态。

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

由于Grunt已经打开，并且因为app.js已经从其他几个js文件中生成，我们发现在每次使用js文件(也是这个app.js)的操作之后，Grunt再次重新创建app.js。

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

将.gitattributes的内容替换为一行:* binary。这告诉git将每个文件视为二进制文件，它不能对其做任何事情。 检查该消息的违规文件已经消失;如果不是，您可以git checkout——<files>将它们恢复到存储库版本 Git签出——.gitattributes将.gitattributes文件恢复到初始状态 检查文件是否仍然没有标记为已更改。

当repo的贡献者在Linux机器上工作时，或者具有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

同样的问题出现了两次!这两次都是我做了一些更改，然后试图把它们放回去。不能弹出的变化，因为我有很多文件被改变-但他们不是!它们完全一样。

我现在认为我已经尝试了以上所有的解决方案，但都没有成功。在尝试了

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

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

当对文件进行差分时，它会说我已经删除了所有行，然后重新添加它们。

有点令人不安。从今以后，我再也不偷东西了。

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

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

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

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

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

以下是我所做的:

I'd initially done a merge before realising I had this problem and had to abort that - git reset --hard HEAD (I ran into a merge conflict. How can I abort the merge?) I opened the files in question in VIM and changed to Unix (:set ff=unix). A tool like dos2unix could be used instead of course committed merged the master in (the master has the DOS-2-Unix changes) git checkout old-code-branch; git merge master Resolved conflicts and the files were DOS again so had to :set ff=unix when in VIM. (Note I have installed https://github.com/itchyny/lightline.vim which allowed me to see what the file format is on the VIM statusline) committed. All sorted!

如果克隆存储库并立即看到挂起的更改，则存储库处于不一致状态。请不要从.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

然后将分支合并(或拉取请求)到回购的所有者。

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

这一页上的其他内容都不起作用。这最终对我有用。没有显示未跟踪或已提交的文件。

git add -A
git reset --hard

试着做一个

Git checkout -f

这将清除当前工作的本地回购中的所有更改

我提交了所有的更改，然后在提交时执行并撤消。 这对我很有效

转到添加 。

git commit -m "随机提交"

git重置-硬头~1

我们公司也遇到过类似的情况。所提出的方法没有一个对我们没有帮助。作为研究的结果，问题被揭示了。问题是在Git中有两个文件，它们的名称只在符号寄存器中有所不同。unix系统认为它们是两个不同的文件，但Windows系统却疯了。为了解决这个问题，我们删除了服务器上的一个文件。在那之后，在Windows上的本地存储库中帮助了接下来的几个命令(以不同的顺序):

git reset --hard
git pull origin
git merge

对我来说，问题是在执行命令时打开了Visual Studio

Git签出<文件>

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

通常情况下，在GIT中使用以下两个命令可以很好地清除你所有的修改和新文件(注意，这将删除你所有的新文件和你可能创建的文件夹，并将所有你修改过的文件恢复到你当前提交的状态):

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

也许更好的选择是执行“git stash push”，并附带可选消息，如下所示:

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

这也会清除你所有新的和修改过的文件，但是你会把它们都保存起来以防你想要恢复它们。GIT中的Stash从一个分支传递到另一个分支，因此如果您愿意，可以在不同的分支中恢复它们。

作为旁注，如果你已经放置了一些新添加的文件，想要摆脱它们，这应该可以做到:

$ git reset --hard

如果以上这些方法对你都不适用，那就看看之前对我有用的方法吧:

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

另外，在那个时候我不能签出另一个分支，所以我被困在了“开发”分支上。

这就是我所做的:

$ git log

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

因为我并不需要它，所以我删除了它:

$ 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列表将显示隐藏的变化，因为我有几个，不需要任何我的存储，我做$ git stash清除删除所有的存储。

注意:在我之前，我还没有尝试过别人建议我做的事情:

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

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

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

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

然后我进入。git / refs / heads / name_branch 并将最后一个committer代码的id放在这里

我是这样解决的:

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

这对我来说很有效。

一个建议的解决方案在这里没有工作，我发现文件实际上是一个链接到一些特殊字符:

% 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

我有一个老的冗余分支，有不同的行尾。切换到这个让我有点卡住了，直到我用了一些力。

git checkout mainbranch --force

接着是一个快速的git分支-D brokenbranch。