通常情况下，在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

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

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

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

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

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

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

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

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

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

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

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

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

git checkout mainbranch --force

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

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

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

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

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

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

我们的问题是，我们没有对结束行进行强制执行，并且存储库混合使用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!