Git 忽略文件不止 .gitignore——三层忽略机制详解

原文来源：Nelson Figueroa — .gitignore 不是 Git 忽略文件的唯一方式，还有两层更灵活的机制多数开发者不知道

如果你用 Git 已经有一段时间，大概率对 .gitignore 文件不陌生——把不想提交到仓库的文件名写进去，Git 就会自动忽略它们。这几乎是每个 Git 用户的第一课。

但今天要告诉你一个事实：.gitignore 只是 Git 忽略文件机制的冰山一角。

Git 实际上提供了三层忽略文件机制，它们的使用场景和影响范围各不相同。绝大多数开发者只知道第一层（.gitignore），忽略了后面两层，导致很多本可以更优雅处理的情况变得很麻烦。

第一层：.gitignore（项目级，入版本控制）

这是最常用的一层。.gitignore 文件放在仓库根目录下，随代码一起提交，团队成员都能看到。

适用于：

• 编译产物（dist/、build/、*.o）
• 依赖目录（node_modules/、vendor/）
• IDE 配置文件（.vscode/、.idea/）
• 环境变量文件（.env 模板可以提交，但具体值不提交）
• 系统文件（Thumbs.db、.DS_Store）

node_modules/
dist/
.env
*.log

优点：团队共享，统一管理。新增成员 clone 仓库后自动生效，不用额外配置。

缺点：所有成员共享同一个忽略规则。有些文件你个人不想提交但同事并不介意，.gitignore 就不太合适了。

第二层：.git/info/exclude（仓库级，不入版本控制）

每个 Git 仓库目录下都有一个 .git/ 目录，里面藏着大量管理数据。其中 .git/info/exclude 是一个特殊的忽略文件——它的语法和 .gitignore 完全一样，但修改它不会被 Git 跟踪，也不会被推送。

换句话说，它只对你当前这个仓库的本地副本生效。

适用场景：

• 个人笔记：你在仓库里放了一个 notes.txt 记录自己的开发思路，不想提交但也不适合写在团队共享的 .gitignore 里
• 本地调试文件：比如 debug.log、临时测试脚本 test-temp.py
• 本地 IDE 配置差异：团队用 VSCode，但你自己用 Neovim，.vimrc 相关的临时文件

操作示例：

# 编辑 .git/info/exclude
echo "notes.txt" >> .git/info/exclude
echo "debug.log" >> .git/info/exclude

打开 .git/info/exclude 文件看看，你会发现它默认就有一些注释行，告诉你这个文件的作用。

# 默认内容通常是一组注释
# .git/info/exclude 的内容格式与 .gitignore 完全一致

优点：只影响当前仓库的本地副本，不影响团队其他人。非常适合个人工作流特有的文件。

缺点：每个仓库都要单独配置，不能跨仓库复用。

第三层：~/.config/git/ignore（机器级，全局忽略）

这是最不为人知但最强大的一层。Git 支持一个全局忽略文件，位于 ~/.config/git/ignore。任何写在这个文件中的规则，会在你本机的所有 Git 仓库中生效。

适用场景：

• 操作系统生成的文件：macOS 上的 .DS_Store、Windows 上的 Thumbs.db
• 编辑器全局残留文件：*~（Vim/Emacs 备份文件）、*.swp
• 全局工具生成的缓存文件：比如 *.pyc、.pytest_cache/

.DS_Store
Thumbs.db
*~
*.swp
*.pyc

优点：一次配置，所有仓库生效。把全局通用的忽略规则放在这里，就不用每个项目的 .gitignore 都重复写 .DS_Store 了。

缺点：影响所有仓库，添加规则要谨慎——如果某天你写了一条过于宽泛的规则，可能无意中忽略掉你本机所有仓库的重要文件。

自定义全局忽略文件位置

如果你不喜欢默认的 ~/.config/git/ignore 路径，Git 允许你通过配置修改它：

# 将全局忽略文件设为 ~/.gitignore_global
git config --global core.excludesFile ~/.gitignore_global
 
# 如果想恢复默认
git config --global --unset core.excludesFile

这个配置被个人开发者广泛使用，尤其是那些需要在多台机器之间同步 Git 配置的人。你把全局忽略文件放在 Dropbox 或 iCloud Drive 里，所有设备都能共享。

如何检查文件被哪一层忽略了？

有时候你会遇到一个奇怪的现象：明明 .gitignore 里没有写某个文件，但 git status 里就是不显示它。这时候你需要一个神奇的调试命令——git check-ignore。

git check-ignore -v <文件名>

-v 参数会告诉你该文件是被哪个规则、哪个文件、哪一行忽略的。

来看看不同情况下的输出：

被 .gitignore 忽略：

$ git check-ignore -v .DS_Store
.gitignore:1:.DS_Store	.DS_Store

被 .git/info/exclude 忽略：

$ git check-ignore -v .DS_Store
.git/info/exclude:7:.DS_Store	.DS_Store

被全局忽略文件忽略：

$ git check-ignore -v .DS_Store
/Users/you/.config/git/ignore:2:.DS_Store	.DS_Store

被自定义全局忽略文件忽略：

$ git check-ignore -v .DS_Store
/Users/you/.gitignore_global:1:.DS_Store	.DS_Store

如果没有任何文件忽略它： 没有任何输出——git check-ignore -v 会安静地返回空。

这个命令在排查「为什么这个文件没被跟踪」时极其好用。很多时候你删了 .gitignore 里的某条规则发现还是不管用，一查才发现是全局忽略文件在作祟。

三层机制对比总表

这三层忽略规则的优先级是：项目级 > 仓库级 > 全局级。也就是说，如果同一个文件在三层中设置了不同的规则，最具体的（项目级）会胜出。

最佳实践建议

1. 团队相关的规则放 .gitignore：编译产物、依赖目录、语言特定的临时文件。这些是所有开发者都需要忽略的。

2. 个人临时文件放 .git/info/exclude：你的调试日志、个人笔记、本地测试脚本。这些不需要打扰其他成员。

3. 系统和编辑器文件放全局忽略：.DS_Store、Thumbs.db、*.swp——这些你应该在所有仓库中忽略，而不是在每个项目的 .gitignore 里重复写。

4. 不确定时用 git check-ignore -v 排查：当 Git 行为出乎意料时，先查清楚是哪个文件、哪条规则在起作用。

5. 避免过度使用全局忽略：太宽泛的规则（比如 *.log）可能会让你错过本该提交的日志文件。

很多人用 Git 几年都不知道这三层机制的存在。一旦掌握了，你会发现很多之前需要小心翼翼地处理的情况，其实都有更优雅的解决方案。