未跟踪的文件未显示为git状态

我有一个具有以下文件夹结构的项目：

所有项目文件都在base_fldr文件夹中。此外，我在base_fldr中有几个文件夹，称为sub_fldr1和sub_fldr2。这些子文件夹还包含一些文件

如果我修改了base\u fldr或base\u fldr\sub\u fldr\中的任何文件，那么git status会将它们显示为已修改。另外，如果我向base_fldr添加一个新文件，git status将显示为未跟踪文件

我的问题是，如果我在base\u fldr\sub\u fldr\中添加了一个新文件，那么git状态不会将该文件显示为未跟踪。它甚至不会提供任何有关该文件的信息

文件或其扩展名不在my.gitignore列表中。我也尝试了git add sub_fldr\file_name，但既没有给出错误，也没有将文件添加到索引中

---

知道这里发生了什么吗？谢谢

您的

sub\u fldr

目录中是否有

.git

子目录？Git可能认为您正在尝试使用。

这可能是因为您的基本\u fldr\sub\u fldr\目录未被跟踪，如果您运行：

git add base_fldr\sub_fldr\

从工作副本根目录中，它将自动添加目录以及该目录中的其他文件和目录

---

默认情况下，git不会显示未跟踪目录中的文件。

我发现了问题所在。基本上，我的.gitignore文件的第一行是“*/”。这会导致git status命令忽略添加到子目录的任何文件。但有趣的是，如果我修改子文件夹中的任何文件，git status会正确地将它们显示为已修改，因为该文件已经在git存储库中，但忽略了子文件夹中的新文件

我修复了我的问题，删除了.gitignore文件中的行以不忽略子文件夹中的更改，然后将新文件添加到索引中，然后再次添加回.gitignore中的行，以便忽略子文件夹中生成的任何文件

---

谢谢大家的回复

这是问题中描述的行为的另一个原因（git status untracked files列表不包括子文件夹中的未跟踪文件）。如果该文件由于子文件夹中的.gitignore文件而未被跟踪，则该文件将不会包含在git status untracked files列表中。

我遇到了一个类似的问题，即缺少跟踪文件。在尝试在不必不断避免意外提交的情况下管理跟踪文件的本地修改版本的方法时，我运行了以下操作：

git update-index --assume-unchanged my-tracked-file-that-is-awol

我最终放弃了这个想法，但忘了撤消该命令，因此对该命令和其他命令的后续更改--假设未更改的文件在以下文件中完全丢失：

git status -u --ignored

我花了一段时间才弄清楚到底发生了什么，但我只需使用以下命令来反转命令：

git update-index --no-assume-unchanged my-tracked-file-that-is-awol

---

为了调试这样的问题，请通过观察以下两个输出，查看

.gitignore

文件是否是罪魁祸首

看

git ls文件--其他--目录--排除标准文件

这将显示所有未跟踪的文件，同时遵守

.gitignore

文件

git ls文件--其他--目录

这将显示所有未跟踪的文件，而不遵循

.gitignore

文件

---

无论哪个文件出现在

2

的输出中，但不出现在

1

的输出中，都不会显示为untracked，因为

中有一些标记。gitignore

文件自2011年以来，这是Git v1.8.3-rc0（2013年4月）首次修复的。
它修复了代码中的一些问题，以遍历工作树来查找未跟踪和/或忽略的文件，清理并优化了代码路径

参见，，，，，，，（2013年4月15日）作者。
（于2013年4月23日被合并）

：使“git status--ignored”在主目录中工作 签字人：卡斯滕·布莱斯

如果“

path

”的某些组件被分类为未跟踪，则“”不会列出“

path

”中被忽略的文件和目录

在遍历前导目录时禁用

DIR\u SHOW\u OTHER\u目录

标志。这可以防止在顶级未跟踪目录中使用

DIR\u SHOW\u IGNORED

标志中止

treat\u leading\u path（）

作为一个副作用，这也消除了每个前导目录级别的递归目录扫描，因为从
treat\u-leading\u-path（）调用时，
treat\u-directory（）
不能再调用
read\u-directory\u-recursive（）


但是，6年后（2019年末），随着Git2.25（2020年第1季度），目录遍历API的各种修复程序。。。恢复上面看到的修复，并重新实现它

参见作者（2019年12月20日）

参见（2019年12月19日）和，（2019年12月10日）作者。

（于2019年12月25日合并）

：使“
git状态--已忽略”
“在主目录中工作”
签字人：以利亚·纽伦

提交（
[
dir.c
]（https
：//github.com/git/git/blob/a2b13367fe55bdeb10862f41aff3e2446b63e171/dir.c）：使“
git状态-忽略
”在主目录中工作”，2013-04-15，git v1.8.3-rc0-）注意到

git status --ignored <SOMEPATH>

用于在忽略
t/
时在
t/
下显示未跟踪的文件，然后将行为更改为停止在忽略的目录下显示未跟踪的文件

更重要的是，此提交考虑保留此行为，但注意到当指定多个PathSpec并因此拒绝它时，它将与该行为不一致

当指定一个pathspec与零或两个pathspec时，出现这种不一致的原因是，pathspec的公共前缀是通过一组不同的检查发送的（在
treat\u leading\u path（）
），而不是正常的文件/目录遍历（通过
read\u directory\u recursive（）
和
treat\u path（）
）

因此，为了一致性，需要检查两个代码路径
git status --ignored | grep <SOMEPATH>

git ls-files -o --exclude-standard t/

git ls-files -o .git/                        # case A

git ls-files -o --exclude-standard t/        # case B

git ls-files -o --directory untracked_dir/   # case C