| English | 中文 |
AI 可以替我们完成越来越多的操作。但一个人能提出什么问题、看见哪些选择、判断什么结果，仍然受到自身理解的影响。脑中没有一个概念，遇到问题时就很难想到使用它，也很难发现一个看似合理的答案漏掉了什么。
这是我继续维护这个仓库的原因：把值得传承的工程思想讲清楚，让人在 AI 的帮助下做出有根据的判断。
过去，学习工具常常意味着把两件事一起学会：理解它的设计，熟练执行它的操作。时间有限时，容易先记住命令，再把原理留到以后。
现在，Agent 可以承担大量操作，理解的重要性变得更明显。知道“可以把改动拆开验证”，才会想到要求 Agent 拆分提交；知道“分支只是引用”，才会在误删分支后先检查提交是否仍然存在；知道“工作区和 Index 可以不同”，才会追问测试与提交是否对应同一份代码。
这也不意味着操作知识失去价值。人仍需要读懂关键命令、识别破坏性操作，并在小实验里验证自己的理解。实践让抽象概念有证据，AI 可以帮助我们降低实践成本。
Git 把几种很有生命力的设计组合在一起：以内容标识对象，用快照记录状态，用引用命名历史，用共同祖先理解分歧。这些思想可以迁移到缓存、制品、协作和系统恢复等问题中。
几个容易混淆的边界尤其值得学：
原理依据见 Git Objects 和 Branches in a Nutshell。
Git 的价值也不需要建立在“其他系统都过时了”的说法上。集中式与分布式版本控制各有取舍，先理解约束，再比较设计。相关讨论见 Git 与 SVN。
学习按三个部分展开：
动画帮助看见关系。真正的掌握，是换一个条件后仍然能预测结果，并说出不知道什么。
可以让 AI 解释对象图、生成实验、比较候选方案、执行授权操作、找审查线索。人需要理解目标与边界，评估证据，并为接受何种变化承担责任。具体审批可以由团队规则分配，不能把责任简单推给“AI 说没问题”。
例如 Agent 说“修好了，测试全绿”。你至少应该能够继续问：
这些问题连接了原理与工程管理。Git 是变更控制的基础之一，完整体系还需要测试、审查、权限、制品和发布记录。
先打开交互学习页，再按完整学习路径依次尝试十个主题的文章、交互和临时仓库实验。完成材料阅读或脚本运行后，仍要通过预测、重现和迁移检查自己的理解；接着可尝试一次 Agent 变更的完整验收。需要从原理、一次变更和团队协作之间选择入口时，查看知识地图。
我们的目标：让理解支撑判断，让工具承担执行。