Git 并不会把忽略模式限制在 `.gitignore`。根据 Mihai Dinculescu 于 2026 年 9 月 23 日发表的文章，Git 会从三个位置读取忽略模式，而且这些地方使用相同的模式语法：仓库中的 `.gitignore` 文件、当前克隆专属的 `.git/info/exclude`，以及通过 `core.excludesFile` 配置的全局排除文件。
实际区别在于作用范围。`.gitignore` 中的条目会被版本控制，因此会传送到其他克隆该仓库的人，适合用于共享的构建产物和标准的本地环境目录。`.git/info/exclude` 只影响一个克隆，而且因为它位于 Git 的内部元数据中，所以不会被意外提交。全局文件会作用于同一台机器上的多个仓库，适合处理编辑器或操作系统产生的杂项文件，而不应把这些内容变成项目规则。
这种区别对于私人笔记、代理计划、临时脚本以及其他只在本地有用、与协作者无关的文件非常重要。Dinculescu 会用 `.git/info/exclude` 处理这类文件，例如使用 `echo 'plans/' >> .git/info/exclude` 这样的命令。Git 也可以使用 `$XDG_CONFIG_HOME/git/ignore` 或 `~/.config/git/ignore` 作为全局文件；还可以通过 `git config --global core.excludesFile` 指定其他位置。
忽略规则有一个重要边界：它不会阻止已经被跟踪的文件出现在变更中。对于已被跟踪的文件，必须先通过 Git 将它从跟踪状态中移除，忽略模式才能在正常的状态输出中将它排除。因此，排除机制属于工作区整理手段，不能替代秘密信息管理、访问控制，也不能替代提交前的仔细审查。
关联工作区还会带来另一个复杂点。在关联工作区中，`.git` 可能是一个指回主仓库的文件，而不是包含 `info/exclude` 的目录。Dinculescu 建议先用 `git rev-parse --git-common-dir` 找到共享的 Git 目录，再把规则追加到该目录下的 `info/exclude` 文件。这样生成的排除文件会覆盖与该仓库关联的关联工作区。
所提供的 GitHub 和 Stack Overflow 个人主页只能确认 Dinculescu 的身份，并不能独立验证上述 Git 行为；技术说明来自主要文章。文章还讨论了一个 Claude Code 文件选择器设置，但所提供的材料没有包含引用的设置文档，因此无法解决该设置名称中的大小写差异。不过，就 Git 本身而言，核心的操作要点很明确：根据预期使用者选择匹配的忽略文件，并记住，让未跟踪文件不再出现在 `git status` 中，并不会改变一个已被跟踪文件是否处于版本控制之下。