把配置写进 .gitignore 后，Git 仍提示它有修改，因为忽略规则主要作用于未跟踪路径。
本文使用Git 2.x 与独立演示仓库。Git（分布式版本管理）保存提交对象和引用，工作区、暂存区与提交历史不是同一份状态。每次操作先判断它改变哪个区域，再决定是否适合当前协作情境。
1. 从现象推到机制
是否被跟踪由索引和历史决定，忽略规则不会自动撤销已有记录。共享配置可以保存无敏感值的模板，机器专属配置通过本地文件或环境提供。把真实密钥提交后再忽略，不会让旧提交中的内容消失。
图中的四个节点分别表示路径状态、忽略匹配、配置分离、历史检查。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
在演示仓库先提交一个普通文件，再添加忽略规则，观察 status。确需停止跟踪时先确认团队约定，不对真实敏感文件做教学实验。
1
2
3
4
5
# .gitignore 示例
target/
*.log
local-settings.properties
# 已跟踪路径需要单独制定迁移方案
示例在没有私人资料的临时仓库执行。先看 status、diff 与 log，再运行改变状态的命令；共享历史优先新增提交表达修复，不用改写历史掩盖已经发生的变化。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 未跟踪日志匹配忽略规则 | 通常不再出现在普通 status 中 |
| 已跟踪配置加入忽略 | 后续修改仍可能被显示 |
| 历史曾出现凭据 | 忽略不能撤销过去暴露 |
对照 1：未跟踪日志匹配忽略规则
通常不再出现在普通 status 中。观察时记录check-ignore 的匹配来源。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：已跟踪配置加入忽略
后续修改仍可能被显示。观察时记录索引是否仍包含该路径。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：历史曾出现凭据
忽略不能撤销过去暴露。观察时记录历史提交与凭据失效处理。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
停止跟踪和清除泄露是不同任务。公开仓库一旦出现有效凭据，应先失效或轮换，再按授权流程处理历史与缓存。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“历史曾出现凭据”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
