知识地图:从理解设计到管理协作
这张地图用于选择阅读路径和下一步决策,不替代命令手册,也不重复十个 Git 原理主题的课程顺序。先判断自己处在哪一层,再进入对应文章。
三层路径
| 层次 |
需要的前置理解 |
这层负责回答的问题 |
从哪里开始 |
下一步要作出的判断 |
| 理解设计 |
愿意在临时仓库中观察一次编辑、暂存和提交 |
Git 到底记录了什么,历史怎样形成,什么状态可恢复 |
为什么在 AI 时代学习 Git → Git 心智模型 → 十个主题学习路径 |
能否说清一次变更在 Working Tree、Index、HEAD 和远端各自的状态?能,进入工程变更;不能,回到对应实验。 |
| 完成工程变更 |
能区分工作区、Index 与已提交版本,并会在发现已有编辑时保留现场 |
怎样把一个明确任务变成范围清楚、证据对应、可以恢复的变更 |
一次工程变更课程 → 接受 Agent 变更 → AI 生成变更的 CI |
这次变更能否独立审查,测试和 CI 是否对应候选或集成提交,出错时代码与外部副作用各如何处理? |
| 管理协作 |
每个变更已能说明任务边界、验证证据和恢复范围 |
团队该选什么协作模型,哪些规则可以落实,案例能否迁移 |
团队 Git 工作流指南 → GitHub 工程治理 → 模板库 → 工程实践决策图谱 |
分支寿命、审批责任、必需检查、发布与恢复由谁定义,规则怎样在仓库和平台中执行? |
Git 的概念学习、一次变更的验收和团队规则彼此相连,但不能互相替代。通过十章实验不等于某次业务变更已经验证;本地测试通过也不等于团队的权限、发布和外部状态已经确认。
关键文章各自负责什么
按眼前问题选择
| 你现在需要决定什么 |
先读 |
接着检查 |
| 一条命令会改动哪份状态 |
Git 心智模型 |
用学习路径中的临时仓库实验复现。 |
| Agent 说“完成了”,我该接受吗 |
一次工程变更课程 |
提交范围、验证版本、制品和运行证据是否能对应。 |
| 后台任务返回得很晚或重复运行,怎样接收 |
后台 Agent 任务 |
任务 ID、base、candidate、目标 ref、证据和接受责任是否一致。 |
| 多个任务同时改仓库,怎么避免互相覆盖 |
Codex / Claude Code Git 实践 |
worktree 或分支是否隔离,谁负责集成和清理。 |
| Agent 误改、删除或留下未知 worktree,先做什么 |
Agent 事故恢复 |
现场、提交范围、共享状态和 Git 外部影响是否已经分开记录。 |
| 团队该使用 GitHub Flow、Gitflow 还是主干开发 |
团队 Git 工作流指南 |
发布节奏、集成频率、CI 能力和回滚成本。 |
| 引入 Agent 后,审查与返工是否改善 |
AI 协作度量 |
等待与实际投入、合并前后返工、观察窗口和任务差异是否分开统计。 |
| 一项公开案例能否照搬 |
两个 AI Agent 工程案例 |
来源是作者自报还是独立证据,你的团队约束是否与案例前提一致。 |
命令、事故案例和模板都是执行辅助。需要它们时从本页进入相应层次,再回到这张地图作下一项决策。