绝大多数“gitignore 坏了”的情况只有一个原因：忽略规则对 Git 已经跟踪的文件无效。先把这个文件从索引里取消跟踪，本地副本不动，提交这次改动，规则立刻开始生效。
🎙️ 发布并录制于： ·
gitignore 只决定哪些未跟踪的文件保持隐身。它不会追溯地把一个路径从仓库里移除。先加规则，再用 cached 这个参数只删索引里的那份记录，然后提交。本地文件仍然留在磁盘上。对一整个文件夹这么做之前先看清路径，那条递归命令会改变它下面所有内容的跟踪状态。
# .env was committed before the ignore rule existed:
git rm --cached .env
git commit -m "Stop tracking .env"
# Whole folder version; local files remain:
git rm -r --cached node_modules/
git commit -m "Stop tracking node_modules"
# Show the matching ignore file, line, and pattern:
git check-ignore -v .env
git status --ignoredfatal: pathspec '.env' did not match any files先确认拼写和当前目录。运行 git ls-files -- .env。没有输出说明索引里没有这条记录，也就不需要删索引，跳过那一步。接着运行 git check-ignore -v .env。如果这条也什么都不打印，那要修的是忽略规则本身，或者 gitignore 文件放错了位置。如果这个文件根本不存在，等应用真的需要时再创建它。
一个裸文件名或者通配符可能在好几个层级上同时匹配。开头的斜杠把规则锚定在仓库根目录。结尾的斜杠表示只匹配目录。两个星号能跨越目录层级，感叹号把路径重新包含回来。规则要从上往下读，因为后面匹配到的规则会改掉前面的结论。
*.log # every .log file, anywhere
build/ # directories named build
/config.json # config.json only at repository root
docs/*.pdf # PDFs directly inside docs
docs/**/*.pdf # PDFs at any depth below docs
!keep.log # exception to an earlier *.log rule
# Keep one file inside an otherwise ignored directory:
!logs/
logs/*
!logs/keep.txt如果 logs/ 被忽略了，Git 就不再往这个目录里走，所以单独写一条 !logs/keep.txt 救不回那个文件。顺序必须是：先把目录重新包含回来，再忽略目录里的内容，最后再重新包含那一个文件。每改一次就跑一遍 git check-ignore -v logs/keep.txt，别靠猜是哪条规则赢了。
先从生成产物、依赖目录、本地环境文件和操作系统留下的垃圾文件开始。别一股脑忽略所有编辑器目录，有些团队会共享有用的工作区配置。真实项目可以拿自己这份短清单去和 GitHub 那个 gitignore 模板仓库对照，然后只留下你看得懂的规则。
# Python
__pycache__/
*.pyc
.venv/
venv/
.env
dist/
*.egg-info/
# Node
node_modules/
dist/
build/
.env
.env.*
npm-debug.log*
# Common local litter
.DS_Store
Thumbs.db
*.swp
.idea/
.vscode/如果被跟踪的那个文件里有密钥，取消跟踪不叫事故处理。旧值还留在更早的提交、别人 fork 出去的仓库、各种缓存和同事的克隆里。第一步是去服务商那边吊销或者轮换这个凭据。然后再把文件从当前跟踪中移除，让应用改用安全的方式读取新值，只有仓库规范确实要求时才用 git filter-repo 清理历史。轮换让泄露的值失去价值，改写历史做不到这件事。