小红帽的灰灰狼1. Git到底维护了几套忽略清单？先说清楚三者的分工
很多人在Git忽略文件这件事上栽跟头，不是因为规则语法看不懂，而是没搞明白Git其实维护了多个独立的忽略清单。你在这边配了规则，那边却不生效，往往是清单选错了。
抛开复杂概念，Git的忽略机制一共有三个层级：项目级忽略（.gitignore）、仓库本地忽略（.git/info/exclude）、全局忽略（core.excludesFile指定的文件）。它们共同决定了哪些文件不会被Git跟踪，但各自的生效范围、传播方式和适用场景完全不同。
先说应用最广泛的.gitignore。它位于仓库目录中（通常在根目录，也可以放在子目录），规则以纯文本形式写在文件里，最关键的一点是：它会随着仓库一起提交，团队里所有人都能共享这套规则。比如前端项目里的node_modules、Python项目里的venv、编译产生的target目录，这些所有开发者都不该提交的东西，写在这里再合适不过。
.git/info/exclude就没那么多人知道了。它藏在.git目录内部，.git目录本身就不会被版本控制，所以这个文件也不会被提交，只对你当前这个仓库副本生效。你可以理解为"私有忽略规则"：比如你本地调试产生的临时文件、某次实验生成的日志、只有你一个人需要忽略的东西，扔这里刚刚好。它不会打扰团队其他人，也不会在推送时被带走。
还有一个全局忽略配置。通过git config --global core.excludesFile指定一个文件，这个文件对整个机器上所有仓库生效。适合放那些你在任何项目里都不想看到的文件：.DS_Store、Thumbs.db、IDE的workspace配置等等。这其实是很多人的盲区——他们把这些本该全局忽略的文件一遍又一遍写进各个项目的.gitignore里。
1.1 三套机制各自的岗位职责
| 清单 | 位置 | 提交仓库 | 生效范围 | 适合放什么 |
|---|---|---|---|---|
| .gitignore | 仓库目录内 | 是 | 所有克隆此仓库的人 | 项目产物、依赖目录、编译输出 |
| .git/info/exclude | .git 目录内 | 否 | 仅当前仓库本副本 | 个人临时文件、本机调试产物 |
| core.excludesFile | 用户目录任意位置 | 否 | 本机所有仓库 | 操作系统文件、IDE无关文件 |
理解这张表的重点不是背位置，而是建立"该放哪"的直觉。我的习惯是先问自己一个简单问题：这个忽略规则，团队其他人需不需要？需要就进.gitignore；只有我自己烦，就进exclude；所有项目都烦，就进全局配置文件。
1.2 既然有三个文件，规则冲突怎么办
很多人还有个疑惑：如果同一个文件在.gitignore里被忽略，又在info/exclude里被取反（!），到底听谁的？
Git的规则是：在一个目录层级内，越靠近文件实际位置的规则优先级越高；跨层级的规则，深层目录中的规则可以覆盖更外层目录的规则。具体到.gitignore、info/exclude、全局配置三者的关系，按优先级从高到低排列是：
- 命令行传递的
-i参数（git add -i交互模式里的规则，日常不常用） .gitignore（包括仓库根目录和子目录的）.git/info/exclude- 全局
core.excludesFile
同时，同一条路径下，后匹配到的规则会覆盖先匹配到的规则，!取反标记可以重新包含之前被忽略的文件。这些规则叠加起来，构成了"最后生效规则获胜"的判定机制。
提示：优先级对应的是"谁最后生效"，不是"谁写完规则谁厉害"。实际排查时，如果一个文件你感觉"明明写了忽略规则却还是被跟踪"，大概率是规则没写对，而不是优先级搞错了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 模式语法的边界语义：斜杠、星号、取反这些细节才是分水岭
忽略规则的语法看着简单，无非是*、?、/、!这几个符号，但实际用起来坑深得很。我见过太多人栽在斜杠上：在.gitignore里写了build/，本意是忽略根目录的build文件夹，结果发现所有子目录下的同名文件夹都莫名消失了——或者说，规则比想象中更宽泛。
先说最基础的规则语义。.gitignore每一行就是一个模式（pattern），它匹配的对象是从当前目录到文件/目录的路径。这里的"当前目录"，取决于.gitignore文件所在的位置：根目录的.gitignore，当前目录就是仓库根；sub/dir/.gitignore，当前目录就是sub/dir。
2.1 pattern开头的斜杠：锚定仓库根目录
模式以/开头，会把匹配锚定到对应的.gitignore文件所在目录的根。举个例子，在仓库根目录的.gitignore里写：
text复制/temp
这意味着只有根目录下那个叫temp的文件或目录会被忽略，但src/temp不会。这个语义特别容易理解错，很多初学者以为开头的/是普通的路径分隔符，其实它起的是锚定作用，告诉Git"我只关心从这里开始的那个路径"。
反过来，如果不写开头的斜杠：
text复制temp
这就变成了"匹配任意层级下名为temp的文件或目录"。src/temp、demo/temp/、temp.txt（注意，这里不写尾部斜杠，连名字里含temp前缀的文件都可能匹配到）全都会被这个模式覆盖。这就是宽泛与精确的差别。
2.2 星号的通配范围：一个星号不能跨目录
*匹配任意长度字符串（但不包括/），所以*.log能匹配debug.log、app-error.log，但匹配不到logs/app/debug.log，因为*不能跨越路径分隔符。这就是最经典的坑：你在根目录写*.log，以为能管住所有层级的日志文件，实际上它只对根目录下的直接文件生效。
要跨目录匹配，得用**双星号。规则里写**/build，意思是对应目录下任意层级中的build文件或目录都会被忽略。而abc/**则表示abc目录下所有内容，包括子目录中的文件（但不包括abc目录本身，所以要让abc目录也被忽略，通常写成abc/或abc/**的组合）。
2.3 目录模式与尾斜杠：/ 的另一个角色
当一个模式以/结尾，它只能匹配目录。比如deploy/只匹配名为deploy的目录，不会匹配同名的文件。这在清理构建产物时非常有用：dist/、build/、target/，这些目录名永远不会和普通文件同名，写尾部斜杠可以让语义更精确。
但注意，不写尾部斜杠的模式比如deploy，它既匹配目录deploy，也匹配文件deploy，还匹配任意名字包含deploy的文件——规则比你想的广泛。所以一个实用建议是：凡是忽略目录，养成加尾部斜杠的习惯。
2.4 取反规则 ! 的局限：目录的排除层级很难打破
取反标记!可以让前面被忽略的文件重新"复活"，有利于白名单式忽略：先忽略一个目录，再用!放行某些需要保留的文件。例如：
text复制build/*
!build/.gitkeep
这段规则的意思是：忽略build目录下所有文件，但保留.gitkeep。很多人会顺理成章地写build/，再写!build/.gitkeep，结果发现不生效。原因在于：如果忽略了目录本身（build/），Git根本不会进入这个目录去检查里面的文件，!build/.gitkeep也就没有机会被匹配到。
正确的做法是忽略目录下的内容而不忽略目录本身：用build/*（忽略目录内所有条目），再通过!build/.gitkeep放行特定文件。这一折腾，就要求你对Git匹配的顺序有清晰认知：先匹配到的忽略规则生效，遇到取反规则时，只要后面的规则能再次匹配上，文件就恢复可见。
2.5 注释与空行：容易被忽略的细节
以#开头的是注释，空行会被忽略。有些人喜欢把#注释写在规则后面，比如*.log # 日志文件，这不会报错，但注释不会生效——Git把它当成模式的一部分，匹配一个名为*.log # 日志文件的东西，其实就是什么都没匹配到。要写注释就单独一行，规则行就老老实实只有规则。
3. 已经tracked的文件为什么无视忽略规则，以及怎么让它"消失"
这是问得最多的一个问题：我明明在.gitignore里写了规则，新文件没问题，但那些已经被Git跟踪的文件却依旧出现在git status里，怎么删都删不掉。
原因其实一句话就能说清：.gitignore的忽略规则，只对未被跟踪（untracked）的文件有效。 一旦某个文件被git add过、提交过，它就进入了Git的索引（index）和提交历史中。忽略规则不会追溯性地把已跟踪文件踢出版本控制，它管的是"以后别再加"，不是"以前加了的给我忘掉"。
3.1 想让它彻底不被跟踪：git rm --cached
这个命令是取消跟踪的关键，作用是从Git索引中移除文件，但保留它在工作区中的实体。也就是说，文件还留在你的磁盘上，只是Git不再对它进行版本控制，并被标记为未跟踪状态。
bash复制git rm --cached config/local.env
执行之后，git status里就会看到一个deleted状态——别慌，这个"deleted"是相对索引而言的，你的磁盘文件还在。提交这次变更后，config/local.env就不再被仓库追踪了。
如果你有一整个目录需要全部取消跟踪，一次删干净：
bash复制git rm -r --cached build/
-r递归处理目录下所有文件，--cached只动索引。这样就能把整个build目录从跟踪列表里拿掉。
3.2 批量清理的思路：先暂停跟踪，再统一提交
现实中你手头可能已经有一堆本该被忽略却已经提交的文件。一个个git rm --cached太累，我喜欢先写忽略规则，再一次性批量移除：
bash复制git rm -r --cached .
注意这个命令的意义：它会把仓库中所有文件从索引移除，但保留工作区文件。执行后所有文件都变成"暂存区里的删除"状态，然后你再执行git add .——此时，新的忽略规则生效，该忽略的不会被重新加入索引，其余文件全部回到跟踪状态。最后提交一次，你的仓库就被"洗"干净了。
提醒：这一步会把所有文件在提交历史里变成"删除+新增"，对于普通项目没影响，但对依赖精细历史记录的项目会制造噪音。谨慎使用。
3.3 让.gitignore对所有人生效的唯一路径
还有一点容易被忽略：.gitignore规则写好了，你的确认也对了，团队其他人却还是看到一堆垃圾文件出现在git status里。原因多半是他们的本地仓库还是老状态——那些文件仍然被跟踪着。
想让忽略规则对已经跟踪的文件统一生效，唯一的办法就是做一次类似上面说的git rm --cached操作并提交推送。 规则本身不会改变任何已提交状态，这是Git设计使然。每次有人问我"为什么我加了.gitignore其他人不生效"，答案基本就落在这里。
4. 排查利器：git check-ignore -v 能告诉你"谁吞掉了我的规则"
遇到忽略规则"不生效"或者"莫名生效"的时候，我们当然可以靠一遍遍读规则文件来猜，但Git其实提供一个非常实用的内置命令，可以直接打印出某条路径到底命中了哪条规则、规则写在哪一行。
bash复制git check-ignore -v build/output.log
输出会是类似这样的格式：
text复制.gitignore:12:build/ build/output.log
解读方式很简单：build/output.log被.gitignore文件第12行的build/规则命中。如果路径没有被任何规则匹配，命令会以非零状态退出且不输出任何内容。
4.1 常见"规则没生效"的排查路径
按照我自身踩坑的经验，规则没生效十有八九是以下几个原因：
- 规则写错了文件：比如知道
exclude的人，把项目级规则写进info/exclude。这个文件不跟随仓库走，团队成员拉下来也不会生效。 - 路径写错层级：写
build的那一行的当前目录是仓库根，但你的build目录在src/build下。此时规则不会匹配src/build。需要在对应层级新建.gitignore，或写src/build。 - 已经被跟踪：文件在加入忽略规则前就被
git add过了。解决办法就是上面说的git rm --cached。 - 目录本身被忽略：如果父目录被忽略，内部文件的取反规则不生效。前面说了目录的排除需要谨慎。
- 没有换行或保存错误：某些编辑器会把
.gitignore存成带BOM的UTF-8，特别老的Git版本会在这个细节上栽跟头（现代版本基本无视）。
4.2 用 check-ignore 排查文件夹目录本身
如果文件路径是目录，也可以用同样的方式检查：
bash复制git check-ignore -v src/
如果你想知道自己写的模式到底会不会匹配某个路径，又不想真的创建这个路径，加一个--no-index参数能让你指定一个不一定存在的路径进行检查（前提是该路径在当前仓库范围内）：
bash复制git check-ignore -v --no-index future_dir/file.txt
这在编写规则时验证语法非常方便，是一个很容易被忽略但几乎是"规则调试利器"的小功能。
5. 一套顺手的忽略配置与常见误区
写到这里，三套机制、语法、排错都说完了，最后分享一套我自己长期在用的配置组合，以及几个容易被绕进去的场景。
5.1 我的默认配置方案
全局配置文件（~/.gitignore_global，通过git config --global core.excludesFile ~/.gitignore_global激活）：
text复制.DS_Store
Thumbs.db
*.swp
*.swo
.idea/
.vscode/
这些是任何项目都不会想要的系统垃圾和编辑器本地配置。注意.idea/和.vscode/这类特定IDE目录历来有争议——如果你的团队统一用某个IDE，而且需要共享配置，那应该反过来把配置提交进仓库，而不应该全局忽略。核心标准是：全局忽略只放"每个人都烦"的东西。
项目级.gitignore（以Node.js项目为例）：
text复制node_modules/
dist/
coverage/
*.log
.env
.vite/
.env这类可能包含密钥的文件最好提交样例但不提交真实文件。常见做法是在仓库里保留.env.example，同时忽略.env。
5.2 什么时候用 .git/info/exclude
info/exclude的典型场景是：同一台机器上同一个仓库有多个克隆，你在其中一个克隆里产生了调试用的本地文件，不想污染仓库工作区。比如我经常在某个克隆里塞一个notes.md记临时想法，这个文件对其他克隆毫无意义，也不该进入版本库，写进info/exclude一行搞定。
另一个典型场景是：本地测试时生成的大文件，比如dataset.bin（200MB），你只在这台机器调试用，不可能提交，也没必要让团队其他人操心，写info/exclude即可。
5.3 两个高频误区再强调一遍
- 空目录根本不需要忽略规则。 Git不跟踪空目录，所以空目录一直不会被提交，这个问题很多人没意识到。需要让空目录保留在仓库里时，习惯是放一个
.gitkeep占位，然后规则按需放行。 .gitignore文件本身该提交就要提交。 有人为了省事把.gitignore也写进自己的info/exclude里，结果新克隆一份仓库后丢失所有规则。这属于过度操作，把项目级规则留在项目里才是正确且负责任的。
写规则这事的核心其实很朴素：同一份仓库里的团队共享规则用.gitignore，个人临时口头规则用exclude，机器级习惯用全局配置。层级搞清楚了，规则语法再烂也崩不到哪去；层级搞错了，语法再严谨也白搭。建议你下次再遇到"这个文件到底谁来忽略"的困惑时，先按这个思路选文件，再动手写规则，绝大多数绕圈的时间都能省下来。