分布式版本控制原理

1. 分布式架构

1.1 集中式 vs 分布式

集中式版本控制（CVCS）：

flowchart TB
    Server["中央服务器（完整仓库）"]
    A["客户端A（快照）"]
    B["客户端B（快照）"]
    C["客户端C（快照）"]
    Server --> A
    Server --> B
    Server --> C

• 所有操作必须联网
• 中央服务器是单点故障
• 分支和标签是服务器端概念

分布式版本控制（DVCS）：

flowchart TB
    Remote["远程仓库（完整仓库）"]
    LocalA["本地A（完整副本）"]
    LocalB["本地B（完整副本）"]
    LocalC["本地C（完整副本）"]
    Remote --- LocalA
    Remote --- LocalB
    Remote --- LocalC

• 每个克隆都是完整仓库
• 离线可执行所有操作
• 无单点故障

1.2 分布式的优势

2. 快照与差异

2.1 存储模型

Git 不存储文件的差异，而是存储文件的快照：

• 版本1：文件 A、B、C 均有完整快照
• 版本2：B 发生变更，存储 B 的新快照；A 和 C 未变更，通过链接指向版本1的快照
• 版本3：C 发生变更，存储 C 的新快照；A 和 B’ 未变更，通过链接指向之前对应快照

核心机制：未变更的文件不会重复存储，而是通过链接引用之前的快照，从而实现高效去重。

2.2 内容寻址存储

Git 使用 SHA-1 哈希作为内容的地址：

# 计算文件的 Git 哈希
echo "hello" | git hash-object --stdin
# ce013625030ba8dba906f756967f9e9ca394464a

相同内容 → 相同哈希 → 只存储一次（去重）

3. 数据完整性

3.1 哈希校验

Git 中的每个对象都通过 SHA-1 哈希校验：

blob、tree、commit 三类对象均通过 SHA-1 哈希唯一标识。

任何数据损坏都会被检测到，因为：

• 修改文件内容 → 哈希变化 → blob 对象变化
• 修改目录结构 → tree 哈希变化 → 上层 tree 变化
• 修改提交 → commit 哈希变化 → 后续所有 commit 变化

3.2 不可篡改性

Git 的数据模型保证了历史不可篡改：

修改任何一个对象会导致其哈希变化，进而使整条哈希链断裂，后续所有提交的哈希都会失效，从而保证历史记录不可篡改。

4. 协作模型

4.1 同步模型

flowchart LR
    工作区 <--"git add / git checkout"--> 暂存区
    暂存区 <--"git commit"--> 本地仓库
    本地仓库 <--"git fetch / git push"--> 远程仓库
    远程仓库 <--"git pull / git push"--> 其他本地仓库

4.2 多远程协作

# 添加多个远程仓库
git remote add origin git@github.com:user/repo.git
git remote add mirror git@gitlab.com:user/repo.git
git remote add upstream git@github.com:original/repo.git

# 从上游同步
git fetch upstream
git merge upstream/main

# 推送到多个远程
git push origin main
git push mirror main

4.3 去中心化协作

Git 理论上支持点对点协作，无需中央服务器：

# 两个人直接交换补丁
git format-patch -1 HEAD       # 生成补丁文件
git apply < 0001-feature.patch # 应用补丁

# 或通过 bundle 交换
git bundle create repo.bundle --all
git clone repo.bundle cloned-repo

5. Git 的性能

5.1 本地操作的速度

几乎所有 Git 操作都是本地操作，不依赖网络：

5.2 压缩存储

Git 使用 zlib 压缩存储对象：

# 查看仓库大小
du -sh .git

# 查看对象数量
git count-objects -v

# 手动压缩
git gc --aggressive

6. 与其他 DVCS 对比