.gitignore 生成器使用指南：按栈组合、去重、再补自定义规则

为什么需要 .gitignore

Git 仓库里不该出现构建产物、依赖目录、本地密钥和编辑器垃圾文件。漏写忽略规则的后果很具体：

• 仓库膨胀：node_modules/、target/、dist/ 动辄数百兆，克隆与 CI checkout 变慢
• 无意义冲突：每人 IDE / OS 产生的配置互相覆盖
• 密钥进历史：.env、私钥一旦提交，删除工作区文件也消不掉历史
• git status 噪音：真正要提交的改动被淹没

.gitignore 生成器 按语言、框架、IDE、工具与操作系统勾选模板，合并时会去掉重复规则，并支持追加自定义行。全部在浏览器本地生成，不会把你的仓库路径上传到服务器。

核心语法（够用的子集）

三条容易踩的坑

1. 已被跟踪的文件不受新规则影响。先 git rm --cached <path>（或谨慎使用对整库的 --cached 重置），再提交。
2. 取反顺序很重要。先宽后窄：先忽略 .env*，再 !.env.example。
3. 空目录不会被跟踪。需要占位时放 .gitkeep，并确保它没被忽略。

还有一条常被忽略：.gitignore 本身要提交。新人只在本机放一份、从不进库，团队就会各写各的，冲突照旧。

在生成器里怎么选

界面按五类展示（可用搜索过滤）：

推荐组合示例：

• 前端：JavaScript/TypeScript + Next.js（或 React）+ VS Code + macOS
• 后端 Go：Go + JetBrains + Docker + 你的 OS
• IaC：语言模板 + Terraform（忽略 .terraform/ 与 *.tfstate）

多选时相同规则（如多处 node_modules/）只会保留第一次出现，输出更干净。

VS Code 模板：忽略私货，保留共享配置

VS Code 模板现在按常见社区写法处理：忽略 .vscode/*，但用取反保留 settings.json / tasks.json / launch.json / extensions.json 与代码片段。这样个人调试用的本地文件仍被挡在仓库外，团队共享的工作区配置可以正常提交。若你的团队约定「.vscode 一律不进库」，删掉那些 ! 行即可。

自定义规则区

模板覆盖不到的路径写在「自定义规则」：例如内部工具缓存目录、公司私有构建产物名。自定义行若与模板重复也会被去重。需要保留示例环境文件时，模板里的 Env 组已包含 !.env.example 一类取反，可按项目再改。

场景：新建 / 团队统一 / 老仓清理

新建项目

初始化仓库后立刻生成并提交 .gitignore，比事后清历史便宜几个数量级。复制下载的文件到根目录即可。

团队统一

把 IDE 与 OS 模板一并勾上，减少「有人提交 .idea、有人提交 .DS_Store」。个人偏好放到全局 excludes：

git config --global core.excludesfile ~/.gitignore_global

全局 excludes 适合「只影响你自己」的条目（本机密钥路径、个人笔记目录）；仓库级 .gitignore 负责团队共识。

老仓已经误提交了依赖

1. 用生成器产出完整规则并提交
2. git rm -r --cached . 后重新 git add .（先备份、先沟通）
3. 提交「停止跟踪被忽略文件」的变更
4. 若曾提交密钥：先轮换密钥，再用 git filter-repo 等工具清历史

清缓存前用 git ls-files | rg 'node_modules|\.env$' 估一下影响面，避免一次 --cached 把不该松开的大文件策略搞乱。

和 Docker 工作流的配合

容器化项目通常同时需要：

• .gitignore：别把密钥和本地产物推进 Git
• .dockerignore：别把同样的东西推进镜像构建上下文

可用 .gitignore 生成器 管 Git，用 Dockerfile 生成器 右侧的 .dockerignore 标签管构建上下文；两者条目会重叠（.env、node_modules），但服务的系统不同，请分别维护。镜像构建好后，若要把历史 docker run 迁到编排文件，再用 docker run 转 compose。

锁文件该不该忽略？

生成器对 Rust/PHP 模板默认不忽略应用侧 lockfile，避免把「可复现构建」误删掉。库作者若明确不提交 lock，在自定义区补一行即可，不要改语言模板去服务少数场景。

规则生效的快速自检

生成或手改之后，用这三条确认意图：

git check-ignore -v path/to/file
git status --ignored
git ls-files --others --exclude-standard

check-ignore -v 会告诉你「哪一行规则命中了」——排查取反顺序时比肉眼扫文件快得多。

Monorepo 与生成目录

单体仓通常仍以根目录一份 .gitignore 为主：先语言模板，再按子应用勾框架（nextjs、django 等），最后 OS + IDE。子目录忽略适合「根忽略、子包偏偏要跟踪」（或反过来）的例外；在嵌套文件里用一行注释写清原因，免得后人「整理」时又全部拍平回根。工具链特有的缓存目录（.turbo/、.parcel-cache/、coverage/）放自定义规则一次即可——不要反复勾重叠的语言模板指望多出一行，生成器会把相同规则合并掉。

FAQ

为什么加了规则 git status 里还有那个文件？

它已经被跟踪。对单个路径：git rm --cached path；确认 .gitignore 生效后再提交。

可以在子目录再放一个 .gitignore 吗？

可以，规则相对该文件所在目录生效。团队规范更建议集中在根文件，子目录规则用于特殊子项目。

误提交密钥怎么办？

视为已泄露：立刻轮换；再清理 Git 历史。只靠后来加入 .gitignore 不够。

生成器去重会不会删掉我需要的注释？

注释行不去重合并逻辑里的「规则指纹」；被合并掉的是完全相同的非注释规则行。区块标题（# === Next.js ===）仍会按模板保留，方便以后对照来源。

排查注记

三条坑按伤害排：已跟踪文件不受新规则影响是头号误解（要 git rm --cached 先取消跟踪）；取反必须先宽后窄；密钥一旦提交，删除工作区文件消不掉历史——所以误提交密钥的处理顺序是先轮换、再清历史，只补 .gitignore 不算处理。自检三条命令里 check-ignore -v 最值钱：它直接告诉你哪一行规则命中，排查取反顺序比肉眼扫文件快得多。lockfile 一节，生成器对 Rust/PHP 默认不忽略应用侧锁文件，理由明说是避免把「可复现构建」误删掉。

本文出自 ToolVault 工具匣。相关工具：.gitignore 生成器、Dockerfile 生成器、docker run 转 compose。访问 首页 查看更多开发者工具。