.gitignore 只对未跟踪文件生效；已提交文件需用 git rm --cached 移除跟踪并提交，才能停止远程同步。
.gitignore 只对未跟踪文件生效；已提交到远程的文件，加了规则也照常同步——这不是配置错了，是 Git 的设计逻辑决定的。
为什么 .gitignore 加了规则，远程分支里还在同步那个文件？
典型现象：config.local.yml 已被 git add 过、提交过、推送到远程，此时你在 .gitignore 里补上 config.local.yml，它依然会出现在 git status 中，且下次 git push 仍可能覆盖远程内容。
根本原因：Git 的忽略机制只作用于「未跟踪（untracked）」文件。.gitignore 不具备“取消跟踪”的能力，它只是“拒绝新跟踪”。
- 判断是否已被跟踪：运行
git ls-files --error-unmatch config.local.yml，若返回路径，说明已被跟踪 - 已跟踪文件的任何修改、删除，Git 都会记录，
.gitignore完全不参与判断 - 新克隆仓库时，该文件不会自动出现，但本地已有历史，所以规则“看起来没用”
git rm --cached 是让远程停止同步的关键操作
要真正让一个已提交文件从远程分支消失（同时保留在本地），必须分两步走，缺一不可：
- 执行
git rm --cached config.local.yml：仅从暂存区移除，工作区文件不动 - 确认
.gitignore中有对应规则（如config.local.yml或config.*），且该行未被更宽泛的规则覆盖（比如前面写了config/，后面写!config.local.yml也无效） - 提交变更：
git commit -m "stop tracking config.local.yml" - 推送：
git push origin main
注意：--cached 是强制要求，漏掉就等于 rm config.local.yml，本地文件直接被删。
斜杠位置写错，.gitignore 规则就失效
匹配范围由 / 的位置严格控制，写错会导致完全不生效或误伤其他文件：
-
logs/：匹配任意层级的logs目录及其全部内容（包括src/logs/、build/logs/） -
/logs/：只匹配项目根目录下的logs/目录，src/logs/不受影响 -
logs（无斜杠）：既匹配logs文件，也匹配logs/目录，且在任意层级生效 -
**/logs/：显式声明多级匹配，语义清晰，推荐用于深度嵌套场景
调试建议：用 git check-ignore -v config.local.yml 查看哪条规则命中、来自哪个 .gitignore 文件，避免靠猜。
团队协作中，别混用 .git/info/exclude 和 .gitignore
三种忽略方式优先级不同，混用容易冲突：
- 项目共享规则 → 必须放
.gitignore（根目录），提交进仓库，所有人共用 - 纯本地临时忽略（如 IDE 的
.idea/、个人日志）→ 编辑.git/info/exclude，不进版本库，不影响他人 - 全局统一忽略（如 macOS 的
.DS_Store）→ 配置core.excludesfile：git config --global core.excludesfile ~/.gitignore_global
优先级顺序是：command line > .git/info/exclude > .gitignore (就近) > global。同名规则以高优先级为准，但 .git/info/exclude 无法被推送，切勿把它当 .gitignore 的替代品来写共享规则。
最易被忽略的一点：所有忽略方式都对「已跟踪文件」无感，git rm --cached 是唯一能切断远程同步链路的操作。规则写得再准，跳过这步，文件照旧上传。
