.gitignore 已加入 .env，Git 仍显示文件修改

.gitignore 里已经写了 .env，修改配置后，git status 仍显示它发生变化，提交时也能把改动带进去。通常是 .env 早已进入 Git 的索引：忽略规则只影响未跟踪文件，不会让已经跟踪的文件自动退出版本管理。

先确认跟踪状态，再检查规则是否匹配。下面以仓库根目录的普通 .env 文件为例。命令在仓库根目录执行，适用于 Git 2.23 及以上版本；回退步骤使用了 git restore。子模块、稀疏检出和正在解决合并冲突的工作区，不直接套用这组操作。

分别确认“已跟踪”和“规则匹配”

先查看当前状态以及索引里的文件：

git status --short
git ls-files --error-unmatch -- .env

第二条命令输出 .env 且成功退出，说明索引中有这个文件，包括已经提交过的文件和刚刚执行过 git add 的新文件。若提示路径未匹配，不要继续移除索引；应检查路径和忽略规则。

接着检查 .env 会匹配哪条规则：

git check-ignore -v --no-index -- .env

--no-index 很关键。默认情况下，git check-ignore 不报告已跟踪文件；省略这个选项后没有输出，不能据此认定规则写错了。

输出会包含规则文件、行号、匹配模式和目标路径。例如，根目录 .gitignore 中的这条规则只匹配根目录 .env：

/.env

如果已有正确规则，就保留它。不要覆盖整个 .gitignore。如果输出的匹配模式以 ! 开头，它是重新包含规则，需要继续检查规则顺序；“命中了一行”不一定意味着文件被忽略。子目录的 .gitignore 也可能覆盖上层规则。

规则仍未匹配时，核对实际文件名、所在目录和规则所在目录。把 .env 加进别的仓库或错误层级的 .gitignore，不会解决当前文件的问题。

停止跟踪会改变后续提交：新的仓库快照不再包含 .env。它适合机器各自维护的本地配置，但不适合团队仍要求统一版本管理的配置文件。

如果程序需要一份默认配置，可以把不含真实凭据的模板作为 .env.example 提交，每台机器另外维护被忽略的 .env。模板应手工整理为示例值，不要把真实 .env 原样复制后直接提交。程序如何读取这两个文件，仍由应用本身决定，Git 不会自动完成配置加载。

如果目标只是暂时隐藏一个仍需共享的配置文件的本地修改，不要把 assume-unchanged 或 skip-worktree 当作通用的忽略开关。它们不能可靠替代“共享模板加本地配置”的安排，后续切换或合并仍可能涉及这个文件。

操作前，把本地 .env 备份到仓库外的私有位置，并确认备份可用。配置里可能有密码或令牌，不要把备份放进另一个会同步或提交的目录。

先查看本次操作会影响哪些内容：

git diff -- .env
git diff --cached -- .env
git diff --cached --name-status

前两条分别显示未暂存和已暂存的改动，涉及凭据的输出只在本机查看。最后一条列出整个暂存区的变化，用来发现与这次整理无关的内容。

如果 .env 在暂存区中还有一份独立改动，先保存那份内容并处理好暂存状态。不要看到移除命令被拒绝，就直接添加 -f 强制执行：git rm --cached 要求索引内容至少与当前提交或磁盘文件中的一份一致，这项检查保护的是只存在于索引里的版本。

确认要停止跟踪后，先预览，再执行：

git rm --cached --dry-run -- .env
git rm --cached -- .env

确认预览只涉及目标文件后，再运行第二条。--cached 让操作只作用于索引，本机工作目录里的 .env 会保留。普通的 git rm .env 则会同时删除工作目录里的文件，不要漏掉这个选项。

原来已提交的文件会出现暂存的删除：下一次提交需要记录“仓库不再包含这个路径”。这不等于本机文件已经被删掉。若文件只是新加入暂存区、从未提交，移出索引后则不会留下同样的删除记录。

不需要对整个仓库执行 git rm -r --cached . 再重新添加全部文件。只处理目标路径，可以保留其他文件的暂存状态。git clean 清理的是未跟踪文件，也不能用来修复这项索引状态；尤其带 -x 时，连已忽略的本地配置也可能被删除。

移出索引后，检查三个结果：

git ls-files -- .env
git check-ignore -v -- .env
git status --short --ignored -- .env
git diff --cached --name-status

第一条不应再列出 .env；第二条应显示预期的有效忽略规则。文件仍存在时，第三条可以用 !! 标识它已被忽略。对于已提交过的 .env，在完成这次提交之前，还需要检查暂存区里的删除记录，不能因为普通状态显示删除就把文件重新加回去。

如果本轮修改了 .gitignore，只暂存该文件：

git add -- .gitignore
git diff --cached --name-status
git diff --cached -- .gitignore

确认暂存区只包含本次要提交的变化后，再提交：

git commit -m "Stop tracking local environment file"

这条命令会提交整个暂存区，因此前面的检查不能省略。已有其他暂存工作时，先按项目流程隔离并保存，不要把无关改动一起提交。若 .gitignore 原本已经正确，也不必为它制造一次修改。

提交后再次执行前面的跟踪和忽略检查，确认磁盘上的 .env 仍在，索引中没有它，且没有待提交的 .env 变化。

团队成员拉取包含该删除记录的提交时，更新可能删除他们工作目录中原来受跟踪的 .env。在合并或分发这一提交前，通知相关人员先备份自己的配置，再按新的本地配置方式恢复；不要把“我的 --cached 保留了文件”理解成所有人的文件都会自动保留。

如果尚未提交，并且 .env 在当前 HEAD 中原本存在，可以只恢复索引：

git restore --source=HEAD --staged -- .env

这条命令让索引重新记录当前提交中的 .env，不会覆盖磁盘上的本地内容。不要额外加 --worktree，否则恢复范围会包含工作目录。随后检查暂存区，并手工撤回本轮新增且不再需要的忽略规则；保留其他人的改动。

如果 .env 从未提交过，HEAD 中没有它，这条命令不能恢复之前那份独立的暂存内容，应使用操作前保存的副本。已经提交或推送的删除记录，则应按团队流程另做修正提交，先确认配置应该共享到什么程度，不要为撤销操作把本地凭据重新加入仓库。

停止跟踪也不会清除旧提交里的 .env。若曾提交过有效密码或令牌，先撤销或轮换这些凭据，再评估历史清理范围；新增一条忽略规则不能收回已经暴露的内容。