Git状态显示修改，Git签出——<文件>Doesn& #39;t remove them

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

行结束归一化

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

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

git config --global core.autocrlf false

除了core.autocrlf，你还可以考虑使用.gitattributes文件。通过这种方式，您可以确保使用repo的每个人都使用相同的规范化规则，防止混合的行尾进入存储库。

如果你想让git在执行不可逆的归一化时警告你，也可以考虑将core.safecrlf设置为警告。

git 手册这样说:

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

不区分大小写的文件系统

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

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

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

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

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

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

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

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

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

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

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

注:这只是一个本地解决方案。下一个克隆回购的人 仍然会被这个问题困住。一个永久的解决办法是 在这里找到: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository . < / p >

问题:无法重置glfw文件。不管我怎么尝试，它们总是显示为修改过的。

解决:

edit .gitattributes


Comment out the line:    # text=auto


Save the file


restore .gitattributes:   git checkout .gitattributes

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

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

我在Windows上有这个问题，但还没有准备好研究使用config --global core.autocrlf false的后果，我也没有准备好放弃其他私人分支和我的收藏中的好东西，并开始一个新的克隆。我只是需要做点事。现在。

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

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

(注意，只运行git reset --hard不够好，在reset之前的文件上运行普通的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

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

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

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

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

当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/ -如果我再次面临这个问题，我会首先尝试一下。

以下是我所做的:

1. 我最初做了一个合并，然后才意识到我有这个问题，不得不中止- git reset --hard HEAD (我遇到了合并冲突。如何终止合并?)

2. 我在VIM中打开有问题的文件，并更改为Unix (:set ff=unix)。当然，可以使用像dos2unix这样的工具

3. 承诺

4. 合并master在(主有DOS-2-Unix更改)

   git checkout old-code-branch; Git合并master

5. 解决了冲突，文件再次是DOS，所以在VIM中必须:set ff=unix。(注意我已经安装了https://github.com/itchyny/lightline.vim，这让我可以看到VIM状态线上的文件格式)

6. 提交。所有分类!

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

git commit -m "随机提交"

git重置-硬头~1

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

git reset --hard
git pull origin
git merge

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

git checkout <file>

关闭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-earlier-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 list将显示存储的更改，由于我的存储很少并且不需要任何存储，所以我使用$ git stash clear来删除所有的存储。

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

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

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

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

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

我是这样解决的:

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

这对我来说很有效。

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

% 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 branch -D brokenbranch。