Git 学习路径：从理解到判断
September 7, 2026 · View on GitHub
English | 中文
先读为什么在 AI 时代学习 Git，再沿“理解设计 → 验证判断 → 管理变更”前进。命令可以随用随查；每一段都要能解释行为，并预测条件改变后的结果。
本页只编排十个 Git 原理主题的学习顺序。需要在原理学习、一次工程变更和团队协作之间选择路径时，使用知识地图。
第一部分：理解 Git 的设计
下面是十个主题的统一顺序。每个主题都有中英文文章、一个交互页和一个可运行的临时仓库实验；从 01 到 03 是既有交互主题，04 到 10 是本轮补入的七个主题。材料和脚本可供检查，读者是否掌握仍需要预测、重现和迁移的实际证据。
| 顺序 | 要回答的问题 | 文章、交互与实验 | 判断练习 |
|---|---|---|---|
| 01 快照与状态 | 编辑、暂存、提交分别记录什么？ | 文章 · 交互 · 实验 | add 后再次编辑，commit 记录哪个版本？ |
| 02 对象图 | commit、tree、blob 各负责什么？ | 文章 · 交互 · 实验 | 为什么两个路径可以指向同一个 blob？ |
| 03 Index | 下一次提交的草稿是什么？ | 文章 · 交互 · 实验 | 如何提交一个文件中的部分修改？ |
| 04 引用与 HEAD | branch、tag、HEAD、detached HEAD 如何关联？ | 文章 · 交互 · 实验 | 分支名移动时，原 commit 会改变吗？ |
| 05 可达性与恢复 | 没有名字的提交还能找回吗？ | 文章 · 交互 · 实验 | reflog 为什么不能当永久备份？ |
| 06 合并与共同祖先 | Git 如何理解两条历史的分歧？ | 文章 · 交互 · 实验 | 没有文本冲突，行为就一定兼容吗？ |
| 07 重放与历史重写 | rebase 为何产生新的 commit？ | 文章 · 交互 · 实验 | 为什么共享历史上的重写需要协调？ |
| 08 远端与同步 | origin/main 和远端 main 有何区别？ | 文章 · 交互 · 实验 | fetch 后，本地工作文件一定变了吗？ |
| 09 worktree 与并行 | 哪些状态共享，哪些状态隔离？ | 文章 · 交互 · 实验 | 两个 Agent 各有分支，为何还可能互相干扰？ |
| 10 存储与维护 | 逻辑快照怎样存得下、查得快？ | 文章 · 交互 · 实验 | 对象图的连线等同于磁盘上的布局吗？ |
维护者可运行 bash scripts/run-git-learning-labs.sh 回归十个实验、三项既有阅读实验、一次本地 Agent 变更验收实验和一次命令安全回归。它只验证脚本描述的临时本地场景，不能测量读者学习效果，也不能证明生产环境状态。
每章按这个顺序练习：先猜结果，操控动画，读完整文章，在临时仓库重现，再改变一个条件重试。恢复能力安排在历史重写前，避免先学危险操作再补救。
第二部分：把原理用于一次真实变更
从一次工程变更课程开始，用一个小修复贯穿任务契约、候选提交、CI、运行证据和恢复：
- 写清期望行为和不允许改动的范围。
- 识别已有编辑，安排分支与工作目录。
- 用 Index 选择要接受的变化，检查 diff。
- 记录并验证具体提交，核对测试覆盖。
- 形成审查决定，确认实际发布版本。
- 解释代码恢复与业务补偿的边界。
继续阅读：接受 Agent 变更、AI 生成变更的 CI、AI 变更审查样例、AI Commit Splitting、Agent 事故恢复。
可用这个问题自查：当 Agent 说“完成了”，能否指出提交范围、验证证据，以及尚未验证的部分？
第三部分：把个人判断变成团队机制
按约束选方案，不必把所有工作流同时引入团队：
| 约束 | 继续阅读 | 需要作出的判断 |
|---|---|---|
| 团队需要统一协作方式 | 团队工作流 | 集成频率、分支寿命、责任如何分配？ |
| 后台或并行 Agent 带来集成压力 | 后台 Agent 任务 → 多 Agent 分支策略 | 每个结果怎样回收，隔离后的成果怎样比较、验证和整合？ |
| 改动之间有依赖 | Stacked PR | 下层变化后，上层证据是否需要更新？ |
| 接受变更需要规则 | GitHub 工程治理 | 哪些权限、检查和审批能真正执行？ |
| 发布有外部副作用 | 发布管理 | 提交、制品、环境和业务结果如何对应？ |
最后再读两个 AI Agent 工程案例和企业工程案例，比较来源、约束与取舍。公开报告提供经验，团队仍要用自己的仓库和验证结果判断适用性。