.gitignore 规则多了以后，文件不出现在 git status 里，直接改忽略文件容易靠猜。到仓库根目录跑：
git check-ignore -v -- path/to/file
输出会告诉你匹配到的是哪个 .gitignore 文件、哪一行和哪条规则。要检查一个已经被 Git 跟踪的文件，可以加 --no-index，按未跟踪文件的规则重新判断。环境：Git 2.x。命令只做匹配检查，不会修改忽略文件。
这个对排查“到底是哪层规则生效”挺省时间。补一个容易混淆的点：文件已经被 Git 跟踪后，命中 .gitignore 也不会自动从索引里消失；--no-index 只是按未跟踪文件的规则重新检查。想确认当前是否已跟踪，可以跑 git ls-files --error-unmatch -- path/to/file，返回成功才说明它在索引里。这样不容易把“被忽略”和“已跟踪但没变化”混在一起。
Nathan03Lv1#1 这个对排查“到底是哪层规则生效”挺省时间。补一个容易混淆的点：文件已经被 Git 跟踪后，命中
.gitignore也不会自动从索引里消失；--no-index只是按未跟踪文件的规则重新检查。想确认当前是否已跟踪，可以跑git ls-files --error-unmatch -- path/to/file，返回成功才说明它在索引里。这样不容易把“被忽略”和“已跟踪但没变化”混在一起。
再补个容易漏的来源：规则不一定在仓库里的 .gitignore，也可能来自 .git/info/exclude 或全局 excludesFile。git check-ignore -v --no-index -- path/to/file 会把实际命中的来源和行号打出来；批量排查时还能用 --stdin，比手动猜规则稳一点。
别熬夜啦Lv1#2 再补个容易漏的来源：规则不一定在仓库里的
.gitignore，也可能来自.git/info/exclude或全局 excludesFile。git check-ignore -v --no-index -- path/to/file会把实际命中的来源和行号打出来；批量排查时还能用--stdin，比手动猜规则稳一点。
还有个小坑：如果命中的规则是目录（比如 build/），只写 !build/app.log 往往救不回来，因为 Git 进不了被忽略的父目录。可以先把父路径也带上检查：git check-ignore -v --no-index -- build build/app.log。需要放行时通常要先放开目录，再忽略其他内容，最后放行目标文件，例如 !build/、build/*、!build/app.log。