为什么 git 不识别我的文件已更改，因此 git add 不起作用

Why doesn't git recognize that my file has been changed, therefore git add not working

提问by somerandomguy

I am trying to push my files to github using bash. They are already on there, and I am uploading a newer version with new lines and code, etc. But when I try git addand then git statusit says:

我正在尝试使用 bash 将我的文件推送到 github。他们已经在那里了，我正在上传一个带有新行和代码等的新版本。但是当我尝试git add然后git status它说：

On branch master

nothing to commit, working directory clean

在分支主

无需提交，工作目录干净

And the file I am using was just modified.

我正在使用的文件刚刚被修改。

回答by ThorSummoner

I had a problem where once upon a time I set the git index to 'assume unchanged' on my file.

我有一个问题，从前我在我的文件中将 git 索引设置为“假设未更改”。

You can tell git to stop ignoring changes to the file with:

您可以告诉 git 停止忽略对文件的更改：

git update-index --no-assume-unchanged path/to/file

If that doesn't help a resetmay be enough for other weird cases.

如果这对其他奇怪的情况没有帮助，重置可能就足够了。

---

---

In practice I found removing the cached file and resetting it to work:

在实践中，我发现删除缓存文件并将其重置为工作：

git rm --cached path/to/file
git reset path/to/file

The git rm --cachedmeans to only remove the file from the index, and resettells git to reload the git index from the last commit.

该git rm --cached只手段从索引中删除该文件，并reset告诉混帐从最后一次提交刷新git的指数。

回答by Marc Eliot Stein

Check your .gitignorefile. You may find that the file, or extension of the file, or path to the file you are trying to work with matches an entry in .gitignore, which would explain why that file is being ignored (and not recognized as a changed file).

检查您的.gitignore文件。您可能会发现文件、文件扩展名或您尝试使用的文件的路径与 中的条目匹配.gitignore，这将解释为什么该文件被忽略（并且未被识别为已更改的文件）。

This turned out to be the case for me when I had a similar problem.

当我遇到类似问题时，事实证明我就是这种情况。

回答by Grady Player

well we don't have enough to answer this question so I will give you several guesses:

好吧，我们没有足够的东西来回答这个问题，所以我会给你几个猜测：

1) you stashed your changes, to fix type: git stash pop

1）您隐藏了您的更改，以修复类型： git stash pop

2) you had changes and you committed them, you should be able to see your commit in git log

2）您进行了更改并提交了它们，您应该能够看到您的提交 git log

3) you had changes did some sort of git reset --hardor other, your changes may be there in the reflog, type git reflog --allfollowed by checking out or cherry-picking the ref if you ever do find it.

3）你做了某种git reset --hard或其他的更改，你的更改可能在引用日志中，git reflog --all如果你找到它，请输入然后签出或挑选引用。

4) you have checked out the same repo several times, and you are in the wrong one.

4) 你已经多次签出同一个 repo，但你错了。

回答by André Cunha

Like it was already discussed, the files were probably flagged with "assume-unchanged", which basicly tells git that you will not modify the files, so it doesnt need to track changes with them. However this may be affecting multiple files, and if its a large workspace you might not want to check them all one by one. In that case you can try: git update-index --really-refresh

就像已经讨论过的那样，这些文件可能被标记为“假设未更改”，这基本上是告诉 git 您不会修改这些文件，因此它不需要跟踪它们的更改。但是，这可能会影响多个文件，如果工作区很大，您可能不想一一检查它们。在这种情况下，您可以尝试： git update-index --really-refresh

according to the docs:

根据文档：

Like --refresh, but checks stat information unconditionally, without regard to the "assume unchanged" setting.

It will basicly force git to track changes of all files regardless of the "assume-unchanged" flags.

无论“假设未更改”标志如何，它基本上都会强制 git 跟踪所有文件的更改。

回答by Monroe Mann

Sounds crazy, but sometimes you are not in the right repo even though you think you are. For example, you may have moved the parent directory, but forgot to switch repos in your text editor. Or vice versa: you're in the right repo in the text editor but the wrong repo in command line. In the first situation, you make your edits in the right filebut it's not the same folder that's open in your command line, so it's actually the wrong file. In the second situation, you actually did edit the right file, but your command line git won't recognize the change because you're not in the correct directory on the command line.

听起来很疯狂，但有时即使您认为自己在正确的存储库中，也没有使用正确的存储库。例如，您可能移动了父目录，但忘记在文本编辑器中切换存储库。反之亦然：您在文本编辑器中位于正确的存储库中，但在命令行中位于错误的存储库中。在第一种情况下，您在正确的文件中进行编辑，但它与在命令行中打开的文件夹不同，因此它实际上是错误的文件。在第二种情况下，您实际上确实编辑了正确的文件，但是您的命令行 git 无法识别更改，因为您不在命令行上的正确目录中。

回答by Joseph Lust

Had a funky thing like this happening. Eclipse Kepler's git plugin was automatically marking all my project folders as ignored in the .gitignore folder.

发生了这样的时髦事情。Eclipse Kepler 的 git 插件会自动将我的所有项目文件夹标记为在 .gitignore 文件夹中被忽略。

When I would got to commiton the Teammenu, they would all set back to ignored. As far as I can tell, this was because I'd set them as derived in the parent project. Unmarking them as derviedfixed this. I'd never seen this before on Indigo. Hope it helps someon.

当我commit进入Team菜单时，他们都会重新设置为忽略。据我所知，这是因为我将它们设置为在父项目中派生。取消将它们标记为已dervied解决此问题。我以前从未在 Indigo 上见过这个。希望它可以帮助某人。

回答by Balraj Gill

I had a similar issue while using Sublime Text-3. After making new changes in the code and saving it, when I tried the git add ./status commands the response was "branch already-up to date". I figured out, regardless saving the updates in the text editor, the file was actually unchanged. Opening file in other editor and saving the changes worked for me.

我在使用Sublime Text-3时遇到了类似的问题。在代码中进行新的更改并保存后，当我尝试 git add ./status 命令时，响应是“分支已经是最新的”。我发现，无论在文本编辑器中保存更新，文件实际上都没有改变。在其他编辑器中打开文件并保存更改对我有用。

回答by antred

We've had this happen on Windows when changing files by transferring differences via the WinMerge tool. Apparently WinMerge (at least the way it's configured on my computer) sometimes doesn't update the timestamps of files it changes.

我们在 Windows 上通过 WinMerge 工具传输差异来更改文件时发生了这种情况。显然 WinMerge（至少它在我的计算机上的配置方式）有时不会更新它更改的文件的时间戳。

On Windows, git status, uses, among other things, a file's time stamp and changes in the file's size to determine whether or not a file has changed. So since the time stamp wasn't updated, it only had the file size to go by. Unfortunately the file in question was a simple version file where the content changed from 7.1.2to 7.2.0. In other words, the file size also remained unchanged. Other files that were also changed by WinMerge and didn't have their time stamps updated but had a different size after the change were detected by git statusjust fine.

在 Windows 上，git status使用文件的时间戳和文件大小的变化等来确定文件是否已更改。所以由于时间戳没有更新，它只有文件大小。不幸的是，有问题的文件是一个简单的版本文件，其中内容从7.1.2更改为7.2.0。换句话说，文件大小也保持不变。WinMerge 也更改了其他文件并且没有更新它们的时间戳，但在git status检测到更改后大小不同。

回答by RBT

TL;DR;Are you even on the correct repository?

TL; 博士; 您是否在正确的存储库中？

My story is bit funny but I thought it can happen with someone who might be having a similar scenario so sharing it here.

我的故事有点有趣，但我认为它可能发生在可能有类似情况的人身上，所以在这里分享。

Actually on my machine, I had two separate git repositories repo1and repo2configured in the same root directory named source. These two repositories are essentially the repositories of two products I work off and on in my company. Now the thing is that as a standard guideline, the directory structure of source code of all the products is exactly the same in my company.

实际上在我的机器上，我有两个单独的 git 存储库，repo1并repo2在名为.gitignore的同一个根目录中进行配置source。这两个存储库本质上是我在公司工作和使用的两个产品的存储库。现在的情况是，作为标准指南，我公司所有产品的源代码目录结构完全相同。

So without realizing I modified an exactly same named file in repo2which I was supposed to change in repo1. So, I just kept running command git statuson repo1and it kept giving the same message

所以没有意识到我修改了一个完全相同的命名文件repo2，我应该在repo1. 所以，我只是不停地运行命令git status上repo1，它不停地给了同样的信息

On branch master

nothing to commit, working directory clean

在分支主

无需提交，工作目录干净

for half an hour. Then colleague of mine observed it as independent pair of eyes and brought this thing to my notice that I was in wrong but very similar looking repository. The moment I switched to repo1Git started noticing the changed files.

半个小时。然后我的同事将它视为独立的一双眼睛，并让我注意到我错了但看起来非常相似的存储库。我切换到repo1Git的那一刻开始注意到更改的文件。

Not so common case. But you never know!

不那么常见的情况。但你永远不知道！

回答by SilverWolf - Reinstate Monica

Did you move the directory out from under your shell? This can happen if you restored your project from a backup. To fix this, just cdout and back in:

您是否将目录从 shell 下移出？如果您从备份恢复项目，就会发生这种情况。要解决此问题，只需cd退出并返回：

cd ../
cd -