我在Windows 8系统上就遇到过这种情况，我在命令提示符下使用Git。我的团队其他成员使用TFS，我使用微软的Git -tf在TFS和我的本地Git存储库之间进行推/拉操作。

问题的产生是由于一些文件被重命名只是为了改变它们的大小写。事情的经过是这样的:

The files were checked in with mixed casing in their names. In a later commit, the file names were changed to all lower-case. git-tf initially got the files in mixed case. When the files were renamed to lower-case, git-tf didn't get the files because to Windows 8 those file names are equivalent. Since Git is case-sensitive, it complained that I had the mixed-case files that weren't in source control. But using git status, I couldn't see any changes, since in the Windows command prompt those file names are equivalent.

对我来说最简单的解决方法是:

Git在添加这些文件之前就签出了以前的项目版本。 然后git用正确的文件套出项目的最新版本。

删除appname/gen/下的.gitignore文件即可解决此问题。

移动文件，而不是删除

避免删除文件的一种方法是移动它们。例如:

cd "`git rev-parse --show-toplevel`"
git checkout 2>&1 | while read f; do [ ! -e "$f" ] || mv "$f" "$f".bak; done

我也面临着类似的问题，我尝试了上面发布的所有解决方案，但都不起作用

当我在开发分支中将我的onmusicupdatelister .java重命名为onmusicupdatelister .java时，导致了这个问题。

master有onmusicupdatelister .java 和develop有和onmusicupdatelister .java相同的文件

现在，每当我切换到master，它就会给我一个错误

The following untracked working tree files would be overwritten by checkout

然后它中止了。

为了解决这个问题，我强制检查了主分支 然后将我的onmusicupdatelister .java重命名为onmusicupdatelister .java，提交它，然后将其合并到开发分支。

然后我更新了我的开发分支合并到主，现在一切恢复正常，问题解决了。

一个简单的解决方案是: 只需确保您在github中的正确工作目录中。 如果用户试图合并文件夹层次结构中太高的目录，几乎每次都会出现该消息。

例子:

/workspace/git/myBashSourceFolder/myProjectSourcefolder

Scenario: User cloned repo in git-folder he created a new Java Project in Eclipse, imported the cloned repo. Eclipse set myProjectSourceFolder as Source Folder in his local Project. therefore the User entered it in git bash and pushed, pulled and commited his project from there. git syncs therefore myProjectSourceFolder - but has no record in his history for myBashSourceFolder. Therefore a push / pull /merge from myBashSourceFolder will produce the given output, if User tries to sync from there next time, instead of the folder he worked before.

解决方案:输入正确的文件夹并再次尝试拉。几乎在每一个 我遇到的时候，这个解决方案工作得很好:)

不幸的是，无论是git rm——cached还是git clean -d -fx ""都没有为我做这件事。

我的解决方案最终是将我的分支推到远程，克隆一个新的回购，然后在新的回购中进行合并。其他获得回购的人也必须这样做。

这个故事的寓意是:从一开始就使用.gitignore文件。