.gitignore对已经在repo中的文件没有任何影响，因此需要使用git rm -cached删除它们。——cached会阻止它对你的工作副本产生任何影响，下次提交时它只会标记为已删除。文件从repo中删除后，.gitignore将阻止它们再次被添加。

但是你有另一个问题与你的。gitignore，你过度使用通配符，导致它匹配少于你期望它。相反，让我们改变。gitignore，试试这个。

.bundle
.DS_Store
db/*.sqlite3
log/*.log
tmp/
public/system/images/
public/system/avatars/

我在根据之前的提交检出到分支时遇到了同样的问题。Git因为未跟踪文件而拒绝签出。

我找到了一个解决办法，希望它也能帮助到你。

将受影响的目录添加到.gitignore并在其中缓存$ git rm -r——显然是不够的。

假设你想基于之前的commit K创建一个分支来测试一些东西，然后回到当前版本。我会按照以下步骤来做:

Setup the untracked files: edit the .gitignore and apply $ git rm -r --cached on the files and directories you want the git to ignore. Add also the file .gitignore itself to .gitignoreand don't forget to issue $ git rm -r --cached .gitignore. This will ensure the the ignore behavior of git leaves the same in the earlier commits. Commit the changes you just made: $ git add -A $ git commit Save the current log, otherwise you may get problems coming back to the current version $ git log > ../git.log Hard reset to the commit K $ git reset --hard version_k Create a branch based on the commit K $ git branch commit_k_branch Checkout into that branch $ git checkout commit_k_branch Do your stuff and commit it Checkout back into master again $ git checkout master Reset to the current Version again $ git reset current_version or $ git reset ORIG_HEAD Now you can reset hard to the HEAD git reset --hard HEAD

注意!不要跳过倒数第二步(例如:$ git reset——hard ORIG_HEAD )否则git上面抱怨的未跟踪文件将会丢失。

我还确保git抱怨的文件没有被删除。我将它们复制到一个文本文件中，并在$(cat ../test.txt)中发出命令$ for I;做ls -ahl $i;完成

如果再次签出到上面提到的分支，不要忘记发出$ git状态，以确保没有不必要的更改出现。

一个简单的解决方案是: 只需确保您在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.

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

这对我很管用。

 1. git fetch --all
 2. git reset --hard origin/{branch_name}

这个命令解决了我的问题:

git add * 
git stash
git pull

我在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用正确的文件套出项目的最新版本。