4.1 版本管理简史
沿版本管理从目录复制、锁定文件、冲突协商到分支与分布式对象图的演进，理解 Git 如何保留变更的共同祖先与语义。
学习目标
- 能沿 blob、tree、commit、ref 与共同祖先追踪一次文件变更如何成为可回溯历史
- 能比较目录复制、锁定文件、冲突协商、分支和分布式对象图各自保存了什么、丢失了什么
- 能在正常、边界和故障场景中定位覆盖目录或错误移动引用造成的首个历史偏离，并用重置轨迹验证修复
4.1 版本管理简史
本页依据刘欣《码农翻身》（2018 年第 1 版）及出版社公开书目信息，独立重构 4.1 版本管理简史。正文、图示、实验和练习是本课程重新设计的教学材料，不复制原书正文、插图、练习答案或代码。
版本管理真正要保存的不是一堆“最终目录”，而是变更发生的顺序、作者、父版本和可合并的差异。演进可以看作五次边界移动：先把目录按日期复制，再用锁定减少覆盖，随后允许冲突并记录差异，接着用分支保存并行历史，最后把历史拆成内容寻址对象，让引用只负责指向某个提交。
三个会让版本历史失真的陷阱
七个目录节点到历史证据
4.1 版本管理简史
总合同是：文件内容先成为不可变的 blob，目录结构成为 tree，提交把 tree 与父提交、作者、消息绑定，ref 指向提交，分支合并依据共同祖先组合两侧变更。复制目录能保留快照，却不能自然表达对象身份与父关系。
“人肉” 版本管理
“人肉” 版本管理 用日期或姓名复制完整目录来留下快照。它的优点是直观，边界是快照之间缺少机器可验证的差异和共同祖先；同名文件来自哪个变更、哪些内容可以安全组合，都需要人工回忆。
↡按日期、姓名或版本号复制完整源码目录的早期做法；保留了快照，却没有结构化的父关系与变更集合。锁定文件：避免互相覆盖
锁定文件：避免互相覆盖 用写锁把同一个文件的编辑权交给一个人。它减少了同时写入，但把协作等待、锁忘记释放和跨文件变更的一致性问题推迟到流程层。
↡通过写锁限制同一文件同时编辑者的协作策略；降低覆盖概率，但也可能造成等待、锁泄漏和跨文件协调成本。允许冲突：退一步海阔天空
允许冲突：退一步海阔天空 不再阻止所有并行修改，而是记录两侧差异，交给合并者判断。冲突不是失败本身，未经理解就选择一侧才会丢失变更语义。
↡允许多个参与者并行修改同一文件，再以差异和冲突标记协商结果的协作方式；关键是保留两侧变更与判断证据。分支：多版本并行
分支：多版本并行 把一条历史上的不同推进命名为不同引用。分支不是目录复制品，而是指向提交的轻量名字；两个分支可以共享祖先，也可以在各自提交后合并。
↡指向某个提交并可随新提交移动的引用名称；它表达一条历史线，不是另一份独立源码目录。分布式管理：给程序员放权
分布式管理：给程序员放权 让每个仓库都能保存对象图和本地提交，再通过交换对象与移动远端引用协作。断网时可以提交，联网时再同步；权限边界从“中央文件锁”转向“谁可以发布或接受哪些历史”。
↡每个参与者都持有可提交的对象图并可离线推进历史，再通过远端对象交换与引用更新协作的版本管理方式。程序员也爱社交
程序员也爱社交 把代码协作变成可审查的历史交流：提交说明变成上下文，分支变成提案，合并变成对共同祖先和两侧变更的公开判断。工具降低了传递成本，但不能替人解释冲突的业务语义。
↡以提交、分支、审查和合并传递变更上下文的协作方式；社交层帮助理解意图，但仍需对象和父关系支撑事实。Lab
版本对象与合并历史实验
只改变并行修改或合并方式，观察对象链、共同祖先与引用状态怎样变化。
文件内容生成 blob，tree 与 commit 顺序完整，main ref 前进
blob:b1 → tree:t1 → commit:c1(parent:c0) → main:c1
判定
accept：对象链、父关系与引用都能从基线重放
当前样本：线性提交；保存对象 ID、父提交、共同祖先、ref 位置和复位结果。
五步重放一条版本历史
1. 写入 Blob 并固定输入
给文件内容、路径和作者一个固定样本，记录内容寻址对象、输入版本和预期哈希。正常样本只改一行，边界样本只改文件名，故障样本把另一侧改动伪装成覆盖目录。
正常、边界与故障证据矩阵
| 样本 | 只改变的变量 | 预期判定 | 必存证据 |
|---|---|---|---|
| 正常 | 一侧改一行后提交 | 新 blob、tree、commit 与 ref 链条完整 | 对象 ID、父提交、ref |
| 边界 | 两侧修改同一文件不同位置 | 依据共同祖先合并且两侧差异均可解释 | 祖先、两侧 diff、合并结果 |
| 故障 | 用目录覆盖代替合并 | 拒绝无父关系或丢失变更语义的结果 | 覆盖前后快照、首个丢失变更 |
故障诊断：先找对象、祖先和引用
- 内容与树：查 blob 内容、路径模式和 tree 条目；文件文本相同不等于路径、模式和目录结构相同。
- 提交与父关系：查 tree、父提交、作者、消息和对象 ID；新提交没有正确父节点时，先拒绝历史链而不是继续合并。
- 引用与同步：比较旧 ref、新 ref、远端 ref 和本地对象是否存在；ref 移动只是指针变化，不能证明对象已发送或已被接受。
- 合并与恢复：以共同祖先计算两侧差异，记录冲突解决与合并提交；恢复后重新检查对象、祖先、ref 和工作区，而不是只看最终文件。
如果合并后少了一段改动，先重建共同祖先和两侧 diff；如果分支切换后历史不见，比较 ref 是否移动而不是对象是否被改写；如果远端没有新提交，查对象是否同步和远端 ref 是否推进。每次只改变一个历史边界，再从干净基线重放。
术语与边界
本页六个术语都必须指向实验中的对象、引用或控制状态：
- “人肉” 版本管理：目录快照，缺少结构化父关系。
- 锁定文件：避免互相覆盖：限制同时编辑者的写锁。
- 允许冲突：退一步海阔天空：保留两侧变更并显式协商。
- 分支：多版本并行：指向提交的可移动引用。
- 分布式管理：给程序员放权：本地对象图与远端交换协作。
- 程序员也爱社交：以提交上下文和审查传递变更意图。
名词解释
本章出现的专业名词，用大白话再讲一遍。
- “人肉” 版本管理
按日期或姓名复制完整源码目录的快照式管理，缺少机器可验证的父关系。
- 锁定文件：避免互相覆盖
通过写锁限制同一文件同时编辑者的协作策略。
- 允许冲突：退一步海阔天空
保留并行修改的差异与冲突，再协商合并结果的方式。
- 分支：多版本并行
指向某个提交并可随新提交移动的引用名称。
- 分布式管理：给程序员放权
每个仓库都可本地提交，再通过对象交换与引用更新协作的方式。
- 程序员也爱社交
通过提交、分支、审查和合并传递变更上下文的协作方式。
练习
练习
问题 1： 两个分支都改了同一个文件，为什么不能直接把其中一份目录覆盖到另一份目录？
问题 2： 移动分支引用后，旧提交是否被修改？如何证明？
问题 3： 修改实验，让两侧在同一文件不同位置提交，再增加同一行冲突；写出两种样本必须保存的证据。
本页小结
- 目录复制保留快照，锁定文件减少覆盖，冲突协商保留差异，分支保存并行历史，分布式对象图保存可追溯父关系。
- blob、tree、commit 和 ref 的职责不同；移动 ref 不会修改 commit，共同祖先决定合并语义。
- 诊断要保存对象 ID、父提交、共同祖先、两侧 diff、引用位置和复位结果，不能只看最终目录。
读完后的自测问题是：面对“文件最终内容正确但历史不可追溯”的版本事故，你能否指出首个丢失对象或父关系的节点，并用同一基线重放修复？