Git ignore文件配置实战经验分享

关于ignore文件，其实没太多好对比的，但有些细节还是得聊聊

最近帮几个新同事配置项目环境，发现他们对各种ignore文件的理解还停留在初级阶段，就想着把这块儿的经验整理一下。虽然ignore文件看起来挺简单的，但实际工作中遇到的坑还真不少。

我主要接触的就是.gitignore，但其实还有.dockerignore、.npmignore、.eslintignore这些，不过核心原理都差不多。今天主要聊最常用的几种，看看各自的优缺点。

Gitignore还是王道，其他都是点缀

说白了，大部分情况下就是用.gitignore，这个不用多说。我比较喜欢用标准的模板，比如Node.js项目的：

# Dependencies
node_modules/

# Testing
coverage/

# Runtime data
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# Environment variables
.env
.env.test
.env.local

# IDE
.vscode/
.idea/
*.swp
*.swo

# Build outputs
dist/
build/

这个配置用了很多年了，基本能满足日常需求。但是！这里有个坑我一直记得，就是全局忽略文件的问题。之前有一次我设置了全局的.gitignore，结果把一些重要的配置文件也给忽略了，找了半天才发现。

后来我就改成了项目级别的配置，全局只留一些IDE相关的，这样保险一点。

Dockerignore的特殊玩法

dockerignore这个东西，刚开始我以为跟gitignore差不多，但实际上差别还挺大的。主要是构建上下文的考虑，我踩过好几次坑。

比如这个配置：

node_modules
npm-debug.log
.git
.gitignore
README.md
Dockerfile
.dockerignore

重点是要排除node_modules，不然构建镜像的时候会把整个node_modules都打包进去，镜像体积瞬间翻几倍。这个坑我第一次就踩了，折腾了半天才搞明白。

另外dockerignore还有一个特点，就是它的匹配规则跟gitignore稍微有点不一样。特别是通配符的处理，有时候你会发现gitignore里正常的模式，在dockerignore里就不生效，这时候就得调整一下。

Npmignore这个玩意儿容易被忽视

.npmignore说实话用得不多，大部分情况下都是用package.json里的files字段来控制发布内容。但我发现有些场景下npmignore还是有用的。

比如你想发布一个库，但不想包含测试文件和文档，这时候就可以用npmignore：

test/
tests/
docs/
*.md
.nyc_output/
coverage/

不过这里有个需要注意的地方，如果你同时有.npmignore和files字段，那么.npmignore会覆盖files的设置。这点官方文档写得挺清楚，但我还是在某个项目上吃过亏。

一般来说我还是倾向于用files字段，因为更直观一些，而且不会和其他ignore文件混淆。

ESLintignore和样式检查的那些事儿

这个相对简单，主要是排除一些不需要做代码检查的文件。我一般这么配置：

node_modules/
dist/
build/
*.min.js
public/lib/
coverage/

有个细节需要注意，ESLint的ignore规则可以结合package.json里的配置一起用，有时候会有意外的效果。比如说我在某个老项目里，因为ignore配置不当，导致某些应该检查的文件被跳过了，后面重构的时候才发现一堆问题。

所以现在我都会在CI/CD流程里加一个专门的ESLint检查步骤，确保ignore配置没问题。

谁更灵活？谁更省事？

说到底，我觉得.gitignore是最实用的，毕竟版本控制是日常工作的一部分。其他的像dockerignore、npmignore都是特定场景下用的。

灵活性方面，Git的ignore确实做得比较好，支持各种复杂的模式匹配，而且可以通过.git/info/exclude来做本地忽略，这个就很方便。

但要说最省事的，我觉得还是直接在package.json里配置files字段，一目了然，不容易搞混。虽然功能没.ignore文件那么强大，但对于大多数场景已经够用了。

实际工作中我发现，很多人容易把不同类型的ignore文件弄混，比如把npmignore的规则用到gitignore里，或者反过来。这就需要团队内部统一一下规范，避免不必要的麻烦。

我的选型逻辑

我的做法比较简单粗暴：

• 版本控制相关的一律用.gitignore
• 构建相关的用对应的ignore文件（dockerignore、webpack的配置等）
• 发布相关的优先用package.json的files字段，复杂场景才考虑.npmignore
• 代码检查相关的各自独立配置

最重要的是要在项目初始化的时候就把这些配置都搞定，不要等到后期发现问题再来调整。特别是团队协作的项目，一旦有人提交了不应该提交的文件，清理起来很麻烦。

另外我还会在项目文档里写清楚各个ignore文件的作用，新成员加入的时候就不会搞错了。

踩坑提醒：这几点一定要注意

首先，如果某个文件已经被Git跟踪了，再加到.gitignore里是不起作用的。这时候需要用git rm –cached命令把文件从暂存区移除。

其次，ignore文件里的路径是相对于ignore文件本身的，这点很多人容易搞错。特别是嵌套目录的情况下，路径计算要特别小心。

最后，不同工具对ignore的支持程度不一样，有时候需要查官方文档确认具体的语法支持情况。不要想当然地认为所有ignore都一样。

以上是我对各种ignore文件的对比总结，其实大部分情况下掌握.gitignore就足够了，其他的根据需要选择使用。希望这些经验能帮到大家，少走一些弯路。