直接说结论：.gitignore 只能忽略「未被 Git 跟踪」的文件；已提交过的文件，加了规则也没用，必须先取消跟踪。
为什么 .gitignore 加了规则却还在 git status 里？
常见现象是：明明写了 *.log，但 app.log 仍显示为 “modified” 或出现在 git status 中。这是因为该文件早已被 git add 过、进入过暂存区，Git 已将其标记为“已跟踪（tracked）”。.gitignore 对已跟踪文件完全无效。
判断一个文件是否已被跟踪：运行 git ls-files –error-unmatch filename，若返回路径说明已被跟踪已跟踪文件的修改、删除都会被 Git 记录，忽略规则不生效新克隆的仓库中，该文件不会自动出现，但本地已有历史记录，所以规则不触发
如何真正忽略已提交的文件？
必须分两步：先让 Git 停止跟踪，再确保它被 .gitignore 捕获。
执行 git rm –cached <file>（如 git rm –cached config.local.yml），这会从暂存区移除但保留在工作区确认 .gitignore 中有对应规则（例如 config.local.yml 或 config.*）提交这次变更：git commit -m "stop tracking config.local.yml"后续该文件的改动将不再出现在 git status 中
注意：–cached 是关键参数，漏掉就会连本地文件一起删。
/ 开头、结尾、不加 / 的区别很关键
斜杠位置直接影响匹配范围，写错会导致规则失效或误伤：
logs/：只忽略名为 logs 的目录（及其所有内容），不忽略 logs.txt 文件/logs/：只忽略项目根目录下的 logs/ 目录，不忽略 src/logs/logs（无斜杠）：同时匹配 logs 文件和 logs/ 目录，且在任意层级（如 build/logs 也会被忽略）**/logs/：忽略所有层级中的 logs/ 目录（推荐用于深度嵌套场景）
实际调试时，可用 git check-ignore -v filename 查看哪条规则命中、来自哪个 .gitignore 文件。
全局忽略 vs 项目级忽略 vs 本地临时忽略
三种方式适用不同场景，混用容易冲突：
项目共享规则 → 放 .gitignore（根目录），可提交，团队共用纯本地不共享的忽略（如 IDE 临时文件、个人 debug 日志）→ 编辑 .git/info/exclude，不进版本库全系统统一忽略（如 macOS 的 .DS_Store）→ 配置全局 core.excludesfile：git config –global core.excludesfile ~/.gitignore_global，然后往该文件里写规则
优先级顺序是：命令行 > .git/info/exclude > .gitignore（就近） > 全局 core.excludesfile。同名规则以高优先级为准。
最常被忽略的其实是“已跟踪文件”的状态切换逻辑——不是加了规则就万事大吉，得先清缓存再补规则，而且斜杠位置一错，整个规则就跑偏。建议每次改完 .gitignore 都用 git check-ignore -v 验证一次。
评论(0)