.gitignore对已提交的.env文件无效，因它只忽略未跟踪文件；.env一旦被git add和commit，便持续受跟踪，需先git rm --cached .env再提交并更新.gitignore才生效。
为什么 .gitignore 对已提交的 .env 文件无效
因为 .gitignore 只作用于「未被 Git 跟踪」的文件。一旦 .env 已执行过 git add 和 git commit，它就进入 Git 的索引（staging area），此后无论怎么改 .gitignore，Git 都继续跟踪它。
检查方法：git ls-files | grep ".env" —— 有输出即说明已被追踪。
- 先执行
git rm --cached .env（保留本地文件，仅从索引移除） - 再提交：
git commit -m "stop tracking .env" - 最后把
.env加进.gitignore才真正生效
多分支下如何确保各环境配置不互相污染
不同分支（如 main、develop、feature/login）可能需要各自独立的配置文件（如 .env.production、.env.develop），但这些文件又不能被提交。关键不是靠分支策略自动隔离，而是靠命名+忽略规则+加载逻辑三者配合。
- 在
.gitignore中明确排除：.env.*、config/*.local、application-*.yml - 应用启动时按当前环境变量（如
NODE_ENV）动态加载对应文件，而非硬编码读取.env - CI 构建时通过
--build-arg或挂载方式注入环境专属配置，不依赖工作树内文件
git worktree 能否解决配置泄漏风险
不能直接解决，但能大幅降低人为误操作概率。每个 git worktree 是独立目录，拥有自己的工作树快照和 HEAD，意味着你在 ../my-feature 下修改或生成的 .env.local，不会出现在主工作区或其它工作树中。
- 创建时用绝对路径或清晰相对路径：
git worktree add ../feature-auth feature/auth - 避免在工作树根目录运行
git add .—— 容易一并提交本该忽略的本地文件 - 建议为每个工作树单独配一个
.git/info/exclude，补充项目级.gitignore未覆盖的临时规则
Docker 构建时如何避免敏感配置混入镜像
构建上下文（build context）默认包含整个工作树，哪怕文件被 .gitignore 排除，只要物理存在，docker build 就可能 COPY 进去。最稳妥的做法是：不在构建上下文中放敏感文件，而是在容器启动时注入。
- 构建阶段不 COPY
.env*类文件：COPY --exclude=.env* . /app（Docker 23.0+ 支持） - 使用多阶段构建，在 builder 阶段只复制源码，不复制配置；runtime 阶段通过
docker run -e或--secret注入 - CI 流水线中用
git worktree创建干净构建目录，再docker build -f Dockerfile.prod，彻底避开开发态文件
真正的隔离不在分支命名，而在每次构建是否从干净、可复现、无副作用的代码快照出发 —— 这个快照必须不含任何本地状态，哪怕它“看起来”被忽略了。
