版本控制系统选型

1. 版本控制系统概述

1.1 什么是版本控制

版本控制系统（Version Control System, VCS）是记录文件内容变化、支持多人协作的时间机器。它让你可以：

• 回溯到任意历史版本
• 比较不同版本之间的差异
• 多人并行开发而不互相覆盖
• 追踪每一次变更的作者和原因

1.2 VCS 发展历程

2. Git vs SVN 核心对比

2.1 架构差异

集中式（SVN）：

         中央仓库
        ┌────────┐
        │  trunk  │
        │  tags/  │
        │  branches/│
        └───┬────┘
      ┌──────┼──────┐
      ▼      ▼      ▼
   开发者A  开发者B  开发者C
  (工作副本) (工作副本) (工作副本)

• 所有操作依赖中央服务器
• 开发者只有工作副本，没有完整历史
• 网络中断时无法提交、查看日志

分布式（Git）：

         远程仓库
        ┌────────┐
        │  main   │
        │  dev    │
        └───┬────┘
      ┌──────┼──────┐
      ▼      ▼      ▼
   本地仓库A 本地仓库B 本地仓库C
   (完整副本) (完整副本) (完整副本)

• 每个开发者拥有完整仓库副本
• 离线也能提交、查看历史、创建分支
• 通过 push/pull 同步

2.2 功能对比

2.3 性能对比

3. 其他版本控制系统

3.1 Mercurial（Hg）

• 语言：Python
• 特点：命令简洁、跨平台、性能优秀
• 代表用户：Mozilla（Firefox）、Facebook
• 状态：活跃度下降，逐渐被 Git 取代

3.2 Perforce（Helix Core）

• 特点：企业级、支持超大仓库、细粒度权限
• 适用：游戏开发（大型二进制资产）、芯片设计
• 缺点：商业软件、成本高

3.3 Fossil

• 作者：SQLite 作者 Richard Hipp
• 特点：内置 Wiki、工单系统、Web 界面
• 适用：小型项目、个人项目

4. 选型决策

4.1 选择 Git 的场景

• 开源项目：GitHub/GitLab 生态
• Web/移动开发：行业标准
• 微服务架构：多仓库协作
• CI/CD 集成：GitHub Actions / GitLab CI
• 团队分布：远程办公、跨时区协作

4.2 选择 SVN 的场景

• 大文件管理：游戏资产、设计文件
• 目录级权限：需要限制部分目录的访问
• 线性历史：不使用分支的简单项目
• 遗留系统：已有大量 SVN 历史的项目
• 合规要求：某些行业要求集中式审计

4.3 选择 Perforce 的场景

• 超大仓库：数十 TB 的二进制资产
• 游戏开发：Unity/Unreal 项目
• 严格权限：企业级访问控制

5. 迁移策略

5.1 SVN → Git 迁移

# 安装 git-svn
sudo apt install git-svn

# 克隆 SVN 仓库
git svn clone http://svn.example.com/project \
  --stdlayout \
  --authors-file=authors.txt \
  --prefix=svn/ \
  my-project

# authors.txt 格式
# svn_username = Git Name <email@example.com>

# 同步后续 SVN 变更
git svn fetch
git svn rebase

# 推送到 Git 远程仓库
git remote add origin git@github.com:user/project.git
git push -u origin main

5.2 迁移注意事项

1. 保留历史：使用 git svn clone 保留完整提交历史
2. 作者映射：建立 SVN 用户名到 Git 用户的映射
3. 分支转换：SVN 的目录结构（trunk/branches/tags）需映射到 Git 分支
4. 大文件处理：SVN 中的大文件需使用 Git LFS 管理
5. 权限迁移：Git 不支持目录级权限，需通过其他方式实现
6. 钩子迁移：SVN 钩子需改写为 Git 钩子或 CI/CD 流程

6. Git 协作平台