在日常开发中，.gitignore 文件几乎是每个仓库的标配，但真正能将其配置得规范、清晰、可维护的团队并不多见。许多开发者对通配符规则的理解仅停留在表面，忽略否定模式的高级用法，导致要么过度忽略重要文件，要么遗漏了大量应该被排除的产物。本文将从工程实践角度，系统梳理 .gitignore 的模式匹配机制、否定规则的正确用法，以及目录占位的最佳方案，帮助开发者建立一套可复用的配置规范。
通配符规则的核心机制
Git 的忽略模式支持多种通配符，每种符号都有其精确的行为定义，理解这些细节是写出精准规则的前提。
基础通配符
星号 * 匹配任意数量的任意字符，但不包括斜杠 /。这意味着 *.log 会匹配根目录及所有子目录下的 .log 文件，而 build/* 则只匹配 build 目录内部的直接内容。如果需要匹配任意层级目录，则使用双星号 **，例如 **/node_modules 可以匹配任何位置的 node_modules 目录，无论其嵌套深度如何。问号 ? 匹配单个字符，方括号 [abc] 则匹配括号内任意一个字符，这些在处理特定格式的文件名时非常有用。
斜杠的语义差异
尾部斜杠的存在与否决定了规则的作用域。dir/ 明确指向一个目录，而 dir 则可能匹配同名文件或目录。规则开头的 / 表示从仓库根目录开始匹配，例如 /TODO 只忽略根目录下的 TODO 文件，而 TODO 则会递归匹配所有路径中的同名文件或目录。这种语义差异在复杂项目结构中尤为重要，需要根据实际需求谨慎选择。
否定模式的正确打开方式
否定模式以感叹号 ! 开头，用于打破前面的忽略规则，重新追踪特定文件。这是 .gitignore 中最强大但也最容易用错的功能。
典型应用场景
一个常见的场景是：团队需要忽略某个目录下的所有生成文件，但保留其中的配置文件。例如在 cache/ 目录中，忽略所有 .cache 后缀的文件，但保留 cache/config.json 作为模板：
cache/*
!cache/config.json
这种模式的执行顺序至关重要。Git 会按照规则逐行匹配，一旦文件被某条规则忽略，后续的否定规则可以将其重新纳入追踪。因此，如果将 cache/* 放在 !cache/config.json 之后，否定规则将无法生效，因为此时配置文件已经被前面的通配符规则所忽略。另一个需要注意的细节是，如果目录被整体忽略，目录内部的否定规则也无法生效 —— 此时需要先取消对目录的忽略，再在目录内部添加具体的排除规则。
实践中的常见误区
许多开发者在使用否定模式时容易犯的错误是在根目录的 .gitignore 中试图用 !dir/ 来重新追踪已被忽略的目录。实际上，由于 dir/ 规则已经将整个目录及其所有内容标记为忽略状态，单纯的否定前缀无法穿透这一层限制。正确的做法是在父级目录的规则中保留对特定子目录或文件的例外，或者在目录内部创建独立的 .gitignore 文件来精细控制。
目录占位：告别 gitkeep 的工程方案
Git 本身不追踪空目录，这一特性在需要保留目录结构但目录内容均为运行时产物的场景下常常带来困扰。传统做法是创建 .gitkeep 文件来 “占位”，但这种方案的可维护性较差，且无法表达 “这些内容应该被忽略” 的语义。
方案一：目录内自说明式忽略
在目标目录内部创建 .gitignore 文件，忽略该目录下所有内容，同时保留 .gitignore 本身。以 tmp/ 目录为例：
# 忽略此目录下的所有文件
*
# 但保留 .gitignore 自身
!.gitignore
这种方案的优势在于语义清晰 —— 打开目录中的 .gitignore 就能明白该目录的预期用途。同时，任何被应用动态创建的文件都会自动处于忽略状态，无需手动维护规则。推荐将这种模式应用于 logs/、cache/、uploads/、tmp/ 等运行时目录。
方案二：仅用于未来文件
如果目录目前为空，但计划在未来纳入版本控制的文件，应该使用 .gitkeep 作为占位符。例如 migrations/ 目录目前可能没有迁移脚本，但后续将添加数据库迁移文件。此时创建 migrations/.gitkeep 可以确保目录结构被克隆到所有开发者的本地。当真实文件添加后，应及时删除 .gitkeep，避免产生混淆。
决策树：何时使用哪种方案
判断依据可以简化为一个核心问题：该目录的运行时内容是否应该被追踪？如果答案是否定的，优先使用目录内自说明式 .gitignore；如果答案是肯定的，但目前暂无内容，则使用 .gitkeep 作为过渡。团队应在 CONTRIBUTING.md 或内部规范文档中明确这一约定，避免不同开发者采用不同策略导致混乱。
可维护性实践
随着项目规模增长，.gitignore 文件可能变得臃肿且难以维护。以下实践有助于保持配置的可读性和可扩展性。
首先是分而治之的策略。在大型项目中，可以在不同子模块或子系统目录下分别放置 .gitignore 文件，例如 frontend/.gitignore 处理前端构建产物，infra/.gitignore 处理基础设施配置文件的本地副本。这种方式将关注点分离，也便于各模块负责人独立维护。
其次是善用注释和分组。清晰的注释可以帮助未来的维护者理解规则背后的业务逻辑，而空行分隔的不同功能区块则提升了可读性：
# 依赖目录
node_modules/
vendor/
# 构建产物
dist/
build/
# 日志与临时文件
*.log
*.tmp
# 环境配置（本地覆盖）
.env
.env.local
最后是区分全局与仓库级别的忽略配置。编辑器自动生成的配置如 .DS_Store、Thumbs.db 应该在全局级别配置，通过 git config --global core.excludesfile 指定一个全局的忽略文件；而项目特有的产物如构建目录、测试报告则应放在仓库的 .gitignore 中。
总结
.gitignore 的配置质量直接影响开发体验和 CI/CD 流程的稳定性。掌握通配符的精确语义、正确运用否定模式处理例外情况、针对目录占位场景选择合适的方案，这些看似细节的技术点累积起来，能够显著提升项目的可维护性。告别随意添加的 .gitkeep，用自说明式的目录级 .gitignore 替代，既能表达开发者的意图，又能为团队成员提供清晰的指引。
参考资料
- Adam Johnson, "Git: Don't create .gitkeep files, use .gitignore instead"
- Graphite 官方指南，"How to use a .gitignore file"