使用.gitignore生成器保持仓库整洁
📷 Pixabay / Pexels使用.gitignore生成器保持仓库整洁
手动编写.gitignore文件很麻烦，大多数开发者只是从Stack Overflow复制粘贴。这里有更好的方法。
让我们坦诚地谈谈大多数开发者是如何处理.gitignore文件的。他们开始一个新项目，忘记添加.gitignore，在最初几次推送中提交了node_modules或__pycache__或.env，然后手忙脚乱地修复。或者他们谷歌搜索"gitignore node"，复制Stack Overflow上几年前被高票的答案——通常能用，但有时会遗漏一些特定于自己环境的设置。
有更好的方法，大约需要30秒。但首先，让我们了解.gitignore实际上为什么重要，以及用错了会发生什么。
.gitignore比你想象的更重要
关心.gitignore的显而易见的原因：保持仓库整洁。没有人想在代码审查中浏览有5万个文件的node_modules。但还有一些不那么明显的原因会在生产环境中真正困扰开发者。
安全性。 意外提交.env文件是机密信息出现在GitHub上最常见的方式之一。API密钥、数据库密码、服务凭证——这些被提交和推送后，会在几分钟内被自动机器人扫描并利用。GitHub会在检测到凭证时通知你，但那时密钥已经被泄露了。通过.gitignore预防永远比事后清理要好得多。
性能。 充满构建产物、日志文件或二进制资产的仓库克隆慢、拉取慢、工作起来痛苦。如果node_modules进入了仓库历史，没有影响所有贡献者的rebase或filter-branch，就无法轻松删除它。
减少噪音。 操作系统文件（macOS上的.DS_Store、Windows上的Thumbs.db）、IDE配置文件、编辑器交换文件——这些会弄乱diff视图，在使用不同编辑器的团队成员之间制造无谓的冲突。
常见错误
忘记node_modules（或添加太晚）
这非常常见，几乎是一种成人礼。你npm init，写一些代码，git add .，git commit——然后80MB的node_modules就永远进了你的仓库历史。
即使之后把node_modules/添加到.gitignore，它已经被跟踪了。你必须明确取消跟踪：
git rm -r --cached node_modules
git commit -m "stop tracking node_modules"
--cached标志是关键——它从Git的索引（暂存区）中删除文件，而不从文件系统中删除。
提交.env文件
这是危险的一个。含有真实凭证的.env文件绝不应该接触远程仓库。修复很简单：在创建文件之前把.env添加到.gitignore。更好的做法是使用.env.example文件，列出所有必需的环境变量并使用假值或空值——提交那个文件，永远不要提交真实的.env。
# .gitignore
.env
.env.local
.env.production
.env.*.local
注意.env.example或.env.template不应该在.gitignore中——那些是用来共享的。
忽略太多
相反的问题。我见过一些.gitignore文件阻止了整个本应被提交的目录——配置文件、迁移脚本、schema文件——因为有人对通配符太激进了。*.config这个通配符听起来合理，但你会意识到它同样忽略了团队需要的webpack.config.js和jest.config.js。
要具体。忽略输出，而不是输入。
不忽略特定于操作系统的文件
.DS_Store是macOS存储文件夹显示偏好的方式。Thumbs.db是Windows的缩略图缓存。两者都不应该在你的仓库中。全局gitignore是最干净的解决方案，但项目级别的覆盖也是一个好的安全网。
如何使用.gitignore生成器
不用从空白文件开始或从多年前的Stack Overflow答案复制，.gitignore生成器让你在一分钟内为你的实际技术栈构建一个完整、准确的.gitignore。
工作流程如下：
- 打开.gitignore生成器
- 选择你的语言/框架（Node.js、Python、Go、Rust、Java等）
- 选择你的操作系统（macOS、Windows、Linux）
- 选择你的编辑器或IDE（VS Code、JetBrains、Vim等）
- 添加你正在使用的任何其他工具（Docker、Terraform等）
- 复制生成的输出并粘贴到项目的
.gitignore中
生成的输出由社区维护——它包括JetBrains的.idea/目录、VS Code的.vscode/文件夹、macOS的.DS_Store、Python的__pycache__和.pytest_cache、构建目录、日志文件等。
处理已跟踪的文件
将某些内容添加到.gitignore只能防止将来的跟踪。如果文件已经被提交，Git会继续跟踪它，直到你明确告诉它不要。
命令模式：
# 取消跟踪单个文件
git rm --cached path/to/file
# 取消跟踪整个目录
git rm -r --cached path/to/directory/
# 取消跟踪所有内容并根据当前.gitignore重新添加
git rm -r --cached .
git add .
git commit -m "apply .gitignore rules to tracked files"
最后一种方法是核选项，但当你的.gitignore不完整了一段时间时，有时是最干净的解决方案。
个人设置的全局gitignore
大多数开发者不知道或忘记设置的模式：全局gitignore文件。
你的项目.gitignore应该包含与团队中每个人都相关的模式。但有些东西是特定于你个人设置的——你的编辑器、你的操作系统、你的工作流工具。将.DS_Store添加到每个项目的.gitignore可以工作，但会用个人偏好污染项目文件。更干净的解决方案是全局gitignore。
设置方式：
# 创建文件
touch ~/.gitignore_global
# 告诉git使用它
git config --global core.excludesFile ~/.gitignore_global
然后将个人忽略项添加到~/.gitignore_global：
# macOS
.DS_Store
.AppleDouble
.LSOverride
# Windows
Thumbs.db
ehthumbs.db
Desktop.ini
# VS Code
.vscode/
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
# JetBrains
.idea/
*.iml
*.iws
# Vim
*.swp
*.swo
*~
配置好之后，Git会自动在你机器上的每个仓库中应用这些模式。你再也不需要将.DS_Store添加到项目的.gitignore中了。
区别在于：项目.gitignore用于对整个团队有益的项目相关忽略，全局.gitignore用于只对你自己有意义的个人编辑器/操作系统偏好。
通配符何时会适得其反
.gitignore模式中的通配符功能强大，但需要谨慎使用。
*匹配除斜杠外的任何内容。*.log忽略项目中的所有.log文件。
**匹配包括斜杠在内的任何内容。**/logs忽略项目层次结构中任何位置的logs/目录。
开头的/将模式固定到项目根目录。/node_modules只忽略根目录下的node_modules。
末尾的/指定一个目录。build/只忽略名为build的目录。
注意事项：宽泛的模式会捕获超出预期的内容。常见例子：
**/build忽略任何深度名为build的所有目录*.json会忽略你的package.json（不要这样做）- 没有末尾斜杠的
logs也会忽略根目录下名为logs的文件
有疑问时，宁可更具体而不是更宽泛。更新.gitignore后使用git status查看更改实际产生了什么效果。
在第一次提交前检查
设置.gitignore的最佳时机是在你第一次git add .之前。如果你正在启动一个新项目：
git init- 立即添加.gitignore（使用生成器或模板）
- 然后开始添加文件
这个顺序完全防止了"已经被跟踪"的问题。
.gitignore生成器是获得可靠起点的最快方式。为你的技术栈运行它，添加你知道需要的任何项目特定模式，并为个人编辑器设置全局gitignore。十分钟的设置可以节省以后数小时的清理工作。
与干净的.gitignore工作流一起使用的相关工具：
- UUID生成器 — 在环境配置中生成唯一ID时很有用
- Base64编码器/解码器 — 处理环境文件中编码的机密时经常使用
- JSON格式化工具 — 保持配置文件可读