.gitignore必须放在仓库根目录且文件名全小写为.gitignore；它仅对未跟踪文件生效，已跟踪文件需用git rm --cached取消跟踪。
gitignore 文件写在哪才生效
必须放在仓库根目录下，且文件名是 .gitignore（开头带点，全小写）。Git 只认这个路径和名字，放错位置比如子目录里、或者叫 gitignore.txt，完全没用。
常见错误现象：git status 依然显示一堆日志、编译产物、IDE 配置文件；执行 git add . 还是把它们加进去了——八成是 .gitignore 没放对地方，或者根本没提交过这个文件（Git 不会自动创建它）。
- 如果仓库已初始化，先确认当前路径是
git rev-parse --show-toplevel输出的路径 - 新建
.gitignore后，它只对「尚未被 Git 跟踪」的文件生效；已跟踪的文件得手动取消跟踪：git rm --cached <file></file> - Windows 下注意不要用记事本保存成
.gitignore.txt，推荐用 VS Code、Notepad++ 或命令行touch .gitignore
规则语法怎么写才不踩坑
核心就三条：每行一条规则；支持通配符但不支持正则；以 # 开头的是注释。最容易出问题的是斜杠 / 和双星号 ** 的含义差异。
使用场景举例：想忽略所有 node_modules，但保留某个子目录里的 node_modules/legacy？不行，node_modules/ 这条规则一旦匹配，整个目录树都不再扫描子规则。
-
build/→ 只忽略根目录下的build/目录（结尾斜杠表示目录） -
**/build/→ 忽略所有层级的build/目录 -
*.log→ 忽略所有.log文件，但不会影响app.log.bak（因为*不跨路径分隔符） -
!src/main.js→ 在前面有src/规则的前提下，单独“反选”这个文件（注意：仅对已忽略的路径有效）
为什么有些文件死活 ignore 不掉
最常见原因是这些文件已经被 Git 跟踪了。.gitignore 对已跟踪文件完全无效，Git 会持续监控它们的改动。这不是规则写错了，是机制使然。
典型错误现象：删了 .gitignore 里的某条规则，git status 却还是不显示那个文件；或者新加了一条规则，但文件依旧在待提交列表里。
- 检查文件是否已被跟踪：
git ls-files --error-unmatch <path></path>，如果返回路径说明已被跟踪 - 取消跟踪但保留本地文件：
git rm --cached -r <path></path>（加-r处理目录） - 误删了本地文件？别慌，
git checkout -- <path></path>能恢复（前提是没commit过删除操作） - 全局忽略（如
git config --global core.excludesfile ~/.gitignore_global）和项目级.gitignore是叠加的，优先级后者更高
Node.js / Python 项目常用忽略模板怎么选
直接抄模板没问题，但得知道哪些行真有用、哪些可能误伤。比如 __pycache__/ 和 venv/ 是 Python 项目刚需，但 dist/ 在前端项目里才是关键，Python 里反而少见。
性能影响不大，但规则太宽泛会导致 git status 扫描变慢（尤其大目录），兼容性上所有 Git 版本都支持基础语法，但 ** 是 1.8.2+ 才稳定支持。
- Node.js 推荐至少写：
node_modules/、npm-debug.log、dist/、build/ - Python 推荐至少写：
__pycache__/、*.pyc、venv/、.env（注意不是.env.example） - IDE 相关如
.vscode/、.idea/可以加，但团队用统一 IDE 时建议提交配置，而不是忽略 - 别盲目加
*.DS_Store——macOS 系统文件，Linux/Windows 下无意义，加了也没害处但纯属冗余
真正麻烦的是那些已经提交过、后来才想忽略的敏感文件（比如 API Key、数据库配置）。这时候不能只改 .gitignore，得用 git filter-repo 或 git rm --cached 配合重写历史——但重写会影响协作，得所有人重新 clone。这事一旦漏掉，就只能当事故处理。
