被忽视的两个 Git 忽略文件：全局与本地排除配置

你可能只知道一个 .gitignore

几乎每个用过 Git 的开发者都熟悉项目根目录下的 .gitignore 文件。它随代码一起提交，团队成员共享同一套忽略规则，用来把编译产物、依赖目录、日志文件挡在版本控制之外。

但这只是 Git 忽略机制的一部分。除了项目级的 .gitignore，Git 还提供了另外两个鲜为人知的忽略文件，它们分别解决不同层次的问题。理解这三者的分工，能让你的仓库更干净，也能避免把个人配置强塞进团队共享的规则里。

全局忽略：core.excludesFile

第一个被忽视的机制是全局忽略文件。它不属于任何具体仓库，而是作用于你机器上所有的 Git 项目。

配置方法很简单：

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

然后在 ~/.gitignore_global 中写入规则。这个文件最适合放置那些与项目无关、纯属个人环境的产物，比如：

• macOS 的 .DS_Store
• 编辑器缓存目录，如 .idea/、.vscode/
• Vim 的交换文件 *.swp
• 各类临时文件

这些文件的共同特点是：它们由你的操作系统或编辑器生成，与项目本身毫无关系。把它们塞进项目的 .gitignore 其实并不合适——因为你的同事可能用的是完全不同的编辑器，为你的 IDE 配置写忽略规则会污染共享文件。全局忽略正好解决了这个尴尬。

如果你从未设置过 core.excludesFile，可以运行 git config --global core.excludesFile 检查当前值——返回空则表示未配置。部分 Git 客户端（如 GitHub Desktop）在首次安装时会自动创建全局忽略文件，路径因操作系统而异：macOS/Linux 通常在 ~/.gitignore_global 或 ~/.config/git/ignore，Windows 则可能在 %USERPROFILE%\.gitignore_global。值得注意的是，~/.config/git/ignore 是 Git 2.x 的默认查找路径，即使不显式配置 core.excludesFile 也会生效，这意味着你可能已经拥有一个生效中的全局忽略文件而不自知。

本地私有忽略：.git/info/exclude

第二个隐藏机制是每个仓库内部的 .git/info/exclude 文件。它的语法和 .gitignore 完全一致，但不会被提交，因为 .git 目录本身不受版本控制。

它的定位介于项目级和全局级之间：规则只对当前这一个仓库生效，且只对你自己生效。适用场景包括：

• 你在项目里临时生成的调试脚本或笔记
• 某个只有你会用到的本地配置文件
• 你不希望提交、也不方便修改团队 .gitignore 的临时排除项

换句话说，当你想忽略某个文件，但又觉得「这只是我个人的需求，不该影响别人」时，.git/info/exclude 就是最恰当的落脚点。

三层忽略机制如何分工

把这三个文件放在一起看，Git 的忽略体系其实构成了一个清晰的三层结构：

文件	作用范围	是否提交	典型用途
.gitignore	单个项目，团队共享	是	编译产物、依赖、日志
~/.gitignore_global	机器上所有项目	否	编辑器/系统产物
.git/info/exclude	单个项目，仅个人	否	个人临时文件

判断规则该放哪儿，可以用两个维度来思考：这条规则对别人有用吗？（决定是共享还是私有）以及这条规则跨项目通用吗？（决定是全局还是局部）。

对所有人有用且属于项目本身 → .gitignore；只对你有用且跨所有项目 → 全局忽略；只对你有用且仅限当前项目 → 本地 exclude。

除了这三个静态文件，Git 还支持第四种忽略方式：在 .gitignore 文件所在目录的任意子目录中放置同名文件，规则仅对该子目录及其后代生效。这种目录级 .gitignore 常见于 monorepo 或多模块项目，每个子模块维护自己的忽略规则，互不干扰。Git 在匹配时会从文件所在目录向上逐层查找并合并所有 .gitignore 规则，优先级以最近的文件为准。因此严格来说，Git 的忽略体系是「多层级」而非严格的「三层」，但对于绝大多数单仓库项目，理解项目级、全局级、私有级这三层已经足够。

为什么这件小事值得在意

这个话题在 Hacker News 上引发了不少讨论，一个反复出现的观点是：把个人编辑器配置写进项目 .gitignore 是一种常见但不够优雅的做法。它会让共享文件逐渐膨胀，充斥着各种编辑器和操作系统的碎片规则。

合理利用全局忽略和本地 exclude，能让项目的 .gitignore 回归本职——只描述与项目真正相关的忽略规则，保持简洁和可读。这对于开源项目尤其重要，因为贡献者的开发环境千差万别。

养成把规则分层放置的习惯，不会立刻带来性能提升，但长期来看能显著降低仓库的「配置噪音」，也能减少团队之间因为个人环境差异产生的无谓改动。这正是那种知道之后回不去的小技巧。