.gitignore 生成器
勾选项目用到的语言、框架和环境，拼出一份能直接用的 .gitignore。
语言与运行时
框架与工具
编辑器
操作系统
通用
规则怎么读
一行一条规则，# 开头是注释，! 开头表示例外（重新纳入）。结尾的斜杠表示只匹配目录，node_modules/ 不会误伤同名的文件。* 匹配任意字符但不跨目录，** 可以跨目录，所以 **/*.log 能命中所有层级的日志文件。规则里的路径如果包含斜杠，就按仓库根目录解析；不含斜杠（比如 *.log）则在任意层级都生效。
顺序很重要，后写的规则覆盖先写的。.env 和 .env.* 把环境变量文件全排除，紧接着的 !.env.example 又把模板文件放回来——这三行必须按这个顺序写，反过来就失效了。模板拼接时也遵循同样的顺序：先语言和框架，再编辑器、系统，最后是密钥和日志。
加完规则之后
新建仓库时直接把文件保存成 .gitignore 放在根目录即可。已经在跑的项目要记得：规则不会影响已跟踪的文件，需要 git rm --cached 之后再提交。可以用 git status --ignored 确认哪些文件被忽略了、git check-ignore -v 路径 查某条规则是被哪一行命中的，排查「为什么这个文件没被忽略」很方便。
密钥相关的规则建议无论如何都留着。.env、*.pem、*.key 这些一旦提交，光删文件是不够的，git 历史里仍然能翻出来，必须更换密钥并清理历史。想确认某个字符串里有没有敏感信息，可以用数据脱敏；需要生成随机密钥用随机密码生成。
常见问题
已经提交过的文件，加了规则还会被忽略吗？
不会。.gitignore 只对「还没被跟踪」的文件生效，已经在仓库里的文件会继续被跟踪。要先从索引里移除、但保留工作区的文件，执行 git rm --cached <文件>，再把改动提交。之后它才会真正被忽略。
为什么不忽略 package-lock.json、Cargo.lock 这些锁文件？
应用项目应该提交锁文件，这样每个人的依赖版本一致、构建可复现。只有库项目（被别的项目依赖的那种）才会考虑不提交，因为锁文件对下游没有意义。所以这属于项目策略，模板不替你做决定，也没把它列进去。
为什么放行了 .env.example？
.env.example 是给人看的模板，列出需要哪些变量、怎么填，本身不含真实值，应该进仓库。真正的 .env 才必须忽略。规则里先写 .env.* 再写 !.env.example，感叹号表示例外，顺序不能反——后面的规则会覆盖前面的。
密钥已经提交上去了怎么办？
先把密钥作废并换新的，这是第一步，也是唯一能真正止损的一步——只要提交过，就要假设它已经泄露，因为 git 历史、fork、CI 缓存都可能留下副本。然后用 git filter-repo 或 BFG 清理历史，并通知所有协作者重新克隆。仅删除文件再提交是没用的，历史里仍然能翻出来。
全局忽略和项目里的 .gitignore 有什么区别？
项目里的 .gitignore 会跟着仓库走，团队共享；全局忽略（core.excludesFile，通常放在 ~/.config/git/ignore）只影响你自己的机器，适合编辑器临时文件、系统垃圾这类和个人环境绑定的东西。团队共识放项目里，个人偏好放全局。
子目录里能再放 .gitignore 吗？
能，而且规则是逐层叠加的：越靠近文件的规则优先级越高。子目录的 .gitignore 里写的路径相对该目录解析。大型 monorepo 常用这个特性给每个包单独配规则，避免根目录的文件越来越长。