该忽略什么，该提交什么

好的 .gitignore 不以长短评判，而以标准评判。标准只有一个：新 clone 仓库的人，能否仅凭源码和配置重新得到相同的结果。 能重新生成的就忽略，无法重新生成或用于固定结果的就提交。

应当忽略的内容

类别	示例	原因
构建产物	`dist/`, `build/`, `target/`, `.o`, `.class`	可从源码重新生成
依赖安装结果	`node_modules/`, `vendor/`(PHP), `.venv/`	通过清单文件和 lockfile 重新安装
缓存与日志	`.cache/`, `.pytest_cache/`, `*.log`, `coverage/`	每次运行都会变化
本地环境与机密	`.env`, `.pem`, `local.properties`, `.tfstate`	因人因环境而异，或绝不能泄露
个人工具状态	`.DS_Store`, `*.swp`, `.idea/workspace.xml`	与项目无关 (建议使用全局 gitignore)

lockfile：package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock, poetry.lock, uv.lock, Gemfile.lock, composer.lock, go.sum, .terraform.lock.hcl。让所有人安装相同的版本。有些模板(如 Angular)会忽略 lockfile，请检查结果。
示例配置：.env.example, config.example.yml。说明需要哪些值，但不包含真实机密。
构建工具包装器：gradlew 和 gradle/wrapper/、mvnw。确认包装器 jar 没有因 Java 模板的 *.jar 而被忽略。
团队约定的编辑器设置：.editorconfig, .vscode/settings.json, .vscode/extensions.json, .idea/codeStyles/。共享格式化和代码检查设置能让代码审查更轻松。

.gitignore 并非只能放在根目录。子目录中的 .gitignore 以该目录为基准生效，并且优先于上层文件。在 monorepo 中，如果各个包需要的规则不同，分别放在各包的目录中更易读。

repo/
├── .gitignore          # 公共：.DS_Store, .env, coverage/
├── apps/web/.gitignore # .next/, out/
└── services/api/.gitignore # target/

git 只跟踪文件，不保存空目录。像日志目录这样需要目录存在但要忽略其内容时，可以在目录中放一个占位文件，并用否定规则保留它。

/log/*
!/log/.keep

.keep 或 .gitkeep 这类名称并不是 git 的官方功能，只是一种惯例，任何名称都可以。另一种方法是在该目录中放一个内容如下的 .gitignore，它会只保留自身而忽略其余内容。

*
!.gitignore

常见组合是1～2 个语言或框架 + 操作系统 + 编辑器。如果操作系统和编辑器规则已放在全局，可以省略。
检查顺序。 包含否定规则的模板(Gradle、VisualStudioCode)要放在规则范围较广的模板(Java、Kotlin)之后。
去重要以保持含义的方式进行。 同一规则重复出现时行为不变，但会难以阅读。本站的生成器仅在中间没有否定规则时删除重复规则。
保留分节注释。 几个月后能知道每条规则的来源，才能放心地删除。
进行测试。 把用 git ls-files 取得的实际路径放进模式测试，确认没有意外忽略的文件(例如被 Python 模板中 lib/ 匹配到的前端代码)。

像 *.json 这样过于宽泛的规则会把配置文件也吞掉。尽可能收窄路径(/dist/)，并在目录后加上末尾斜杠，以区分同名文件。在规则上方用一行注释写明原因，后来的人就能判断是否可以删除。