WebStorm 设置新建文件自动 git add

场景

当我们在 webstorm 中添加新的文件时，webstorm 首次会提示，新文件是否要自动 git add，当我们选择了不自动 git add 但后面想要修改时，再次添加新文件就不会出提示框了

解决方法

设置的完整路径是：

Settings → Version Control → Confirmation

在 When files are created 这一组下面有三个单选项：

• Add silently — 静默 git add，新建文件自动进暂存区，不再弹提示。
• Show options before adding to version control — 每次弹窗问一次（默认值）。
• Do not add — 不加入版本控制，也不问。

正文说的「选了不自动 add 之后就再也不提示了」，就是因为当时那个弹窗里勾了 Don't ask again，配置被写成了 Do not add。回到这个页面改回来即可。

同一个页面下面还有 When files are deleted 这一组，逻辑一样——删文件时是否自动 git rm。这个我一般也设成 Add silently（对删除来说就是静默 remove），省掉一次确认。

「自动 git add」到底在做什么

WebStorm 这个行为对应的 git 命令就是：

git add <新文件路径>

它把文件从 untracked 状态变成 staged 状态。理解这一点很重要，因为它解释了两个容易困惑的现象。

为什么新文件不 add 就不出现在提交面板里。git 的 git commit 默认只提交暂存区里的内容。WebStorm 的 Commit 面板列出的是「有变更的已追踪文件 + 已暂存的新文件」，一个从未 git add 过的文件对 git 来说是完全陌生的（untracked），所以不会出现在待提交列表里。这就是「明明新建了文件，提交时找不到它」的原因。

为什么文件名颜色不一样。WebStorm 用颜色标记 git 状态，这套颜色对应关系值得记住：

• 红色/棕红 — untracked，从未 git add 过
• 绿色 — 新增且已暂存
• 蓝色/青色 — 已追踪且有修改
• 灰色 — 被 .gitignore 忽略
• 默认色 — 已追踪且无改动

看到新建的文件是红色，就知道它还没进版本控制。

这个设置有个坑：会把不该提交的文件也 add 进去

设成 Add silently 之后，凡是在 IDE 里新建的文件都自动进暂存区。这里有两类风险：

一是敏感文件。新建 .env.local 存本地数据库密码，如果 .gitignore 里还没写这条规则，它会被静默 add，然后跟着下一次提交推上去。密码进了 git 历史之后不是删掉文件就能清掉的——历史里永远留着，得用 git filter-repo 或 BFG 重写历史，而且推过远端的话协作者都要重新 clone。

二是构建产物和临时文件。IDE 里某些操作（运行测试、构建）会生成文件，如果这些路径没被 ignore，也会被自动 add。

所以开这个设置的前提是：.gitignore 先写全。新项目建好第一件事就应该是配 .gitignore。前端项目最基础的一份：

# 依赖
node_modules/

# 构建产物
dist/
build/
.next/
.nuxt/
.output/

# 环境变量（只提交示例文件）
.env
.env.local
.env.*.local
!.env.example

# 日志
*.log
npm-debug.log*
pnpm-debug.log*
yarn-error.log*

# 编辑器
.idea/
.vscode/*
!.vscode/extensions.json
.DS_Store

# 缓存
.cache/
*.tsbuildinfo
coverage/

.env 那几行的写法值得说一下：先忽略所有 .env*，再用 ! 显式放行 .env.example。这样团队里可以有一份「有哪些变量、格式是什么」的模板文件进版本控制，真实值留在各人本地。

WebStorm 有个配套的便利功能：把光标放在一个 untracked 文件上，右键 → Git → Add to .gitignore，会自动往 .gitignore 追加对应的规则，不用手写。

如果不小心 add 了怎么撤

只是 staged 还没 commit — 撤出暂存区，文件内容不动：

git restore --staged <文件>
# 老版本 git 用这个，等价
git reset HEAD <文件>

WebStorm 里对应的操作是在 Commit 面板里右键该文件选 Rollback（注意这个会丢内容）或者直接取消勾选（只是不提交，文件仍然 staged）。想彻底 unstage 用上面的命令更明确。

已经 commit 但还没 push — 把这个文件从最后一次提交里摘出来：

git rm --cached <文件>
git commit --amend --no-edit

--cached 表示只从 git 索引里删，磁盘上的文件保留。--amend 修改上一次提交而不是新建一个。注意 --amend 会改写提交的 hash，所以只对没有 push 过的提交这么做，已经推上去的话协作者会遇到分叉。

已经 push 了敏感信息 — 这时候情况就严重了。正确的处理顺序是：先在服务端把这个凭据吊销/轮换（这一步最重要，比清历史优先），然后再考虑要不要重写历史。因为只要密钥还有效，历史里能不能搜到都是次要的——有人可能已经抓到了。

相关的一个设置：提交前检查

既然在 Version Control 这个页面下，顺手把提交前的检查项也配一下会省很多事。在 Commit 面板底部有一排勾选（老版本在 Settings → Version Control → Commit）：

• Reformat code — 提交前格式化。不建议开，它会格式化整个文件，把你没动过的行也改掉，diff 变得难读。
• Optimize imports — 移除未使用的 import 并排序。这个可以开，副作用小且确实有用。
• Analyze code — 跑一遍 IDE 的代码检查，有 error 级别的问题会警告你。开了会让提交慢几秒，但能挡掉一些明显的错误。
• Check TODO — 提交前检查有没有 TODO 注释。这个通常是噪音，不建议开。

真正的质量门禁应该放在 git hook 里而不是 IDE 里，因为 hook 对所有人生效、也对命令行提交生效。前端项目的标准做法是 husky + lint-staged：

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx,vue}": ["eslint --fix", "prettier --write"],
    "*.{css,scss,less}": ["stylelint --fix", "prettier --write"],
    "*.{json,md}": ["prettier --write"]
  }
}

lint-staged 的关键优势是它只处理已暂存的文件，不会去动整个项目，所以速度可控。这也和本文的主题连上了：文件有没有被 git add，直接决定它会不会被 lint-staged 检查到。