版本管理核心理解（二）：方式与选择（开源项目协作解析）

简介

---

当下有两种主要的管理流程，分布式管理与集中式管理。主要参考两种方式的代表工具Git与Subversion来讲述它们的大致原理。
这里我们分别从几个方面来介绍两种方式的概念轮廓：

1. 存储布局
   1. 都会产生哪些数据，对我们都有什么意义
   2. 数据将如何分布
2. 使用流程
   1. 使用过程都需要哪些操作
   2. 这些操作会以什么样的顺序进行
   3. 开发人员之间的协作模式
3. 如何选择
   1. 两种方式的优缺点
   2. 使用场景大致的总结

一. 存储布局

---

1.数据类型

1. 快照(shortcut): 形象的讲述就是一瞬间地记录，这里表述的是对项目的某一事物地备份，可看作时刻的碎片
   • 对文件的操作备份（添加，修改，删除）
   • 对目录的操作备份（添加，修改，删除）
2. 修订(revision): 词意是表示为了修正，或改善，改进而进行的修改，这里表述的是对项目地一次整体备份，可理解为版本。由一组 快照 构成，可看作时刻
3. 分支(branch): 分支代表的就是前文所说的为生产某一产品所产生的一系列的备份。由一系列 修订 构成，可看作时间线，并始终指向终点（用于回溯与添加）。
4. 工作区域: 物理区域，这里我对一些术语进行了修改，为了便于理解。
   • 编辑区(working area)：我们进行工作的地方（用于修改，当前 修改中的版本(一个版本))
   • 仓库(repository)：存储所有分支的地方(用于存储，已备份的版本(多个版本))
   • 暂存区（属于分布式管理） / 检出区（属于集中式管理）:
     1. 暂存区(staging area)代表的是从仓库取出的修订版本，并逐渐添加来自编辑区的修改最终成为确定的修订版本（用于存放，将备份的版本(一个版本)）
     2. 检出区(administrative area)代表的是从仓库取出的修订版本（用于出错时放弃当前修改恢复原始状态，已备份版本的副本（一个版本））
5. 设备:
   • 本机(local)（自己工作使用的电脑）
   • 远端(remote)（服务器，用于备份的电脑）
     1. 为什么要使用服务器，应为公司是大家一起工作，所以要用一台电脑供大家一起访问来获取当前的版本和上传自己的修改
     2. 为了安全，防止某人意外的删除整个工作结果。

2.数据布局

1. 集中式管理
   • 本机:
     1. 编辑区
     2. 检出区
   • 远端:
     1. 仓库
        集中式管理将 仓库 放到服务器，工作人员只能从取出一份版本存放到 检出区，并复制到 编辑区 进行编辑，然后将 编辑区 的版本进行上传。
2. 分布式管理
   • 本机:
     1. 编辑区
     2. 暂存区
     3. 仓库
   • 远端:
     1. 仓库
        分布式管理将 仓库 放到服务器，工作人员在本机复制 仓库，并取出一份版本放到 暂存区，并复制到 编辑区 进行编辑，然后将所有修改添加到 暂存区。完成修改后将 暂存区的版本存放到本机的 仓库，然后将本地 仓库 上传到服务器的 仓库 中。这就是称作分布式的原因，每个工作人员都是一个 仓库，可以自由开发，然后在合适的时候整体上传。

二. 使用流程

---

这里我只举出主要的操作，让流程能在体现轮廓的前提下缩减操作，以免陷入细节而不易理解。

1.操作术语

1. 克隆：(分布式管理，首次需要的操作)
   • 将服务器的 仓库，复制到本机的 仓库
   • 从本机的 仓库 取出默认的一份版本到 暂存区，然后复制到 编辑区
2. 检出：
   • 从 仓库 取出一份版本到 检出区 或 暂存区，然后复制到 编辑区（会覆盖 编辑区 的修改）
3. 标记：（集中式管理）/添加（分布式管理）：
   1. 标记：将一个文件（泛指，可以是文件，可以是目录）的修改（包含添加，修改，删除）标记为已修改，用于辅助确认有哪些修改属于这次要上传的 修订版本
   2. 添加：将一个文件（泛指，可以是文件，可以是目录）的修改（包含添加，修改，删除）生成 快照 添加到 暂存区，这时已经产生了备份，都将一点点的备份到 暂存区，构成临时 修订
4. 提交：
   1. 集中式管理 完成编辑后，将处于 编辑区 被 标记 的文件（泛指）作为 快照 上传到服务器的 仓库，构成 修订
   2. 分布式管理 完成编辑后，将处于 暂存区 的临时 修订 直接添加到本地 仓库 中（这里会有些细节差异，但为了理解后文解释）
5. 推送：（分布式管理）
   • 将本地 仓库 相对于服务器的 仓库 多出的 修订 上传到服务器的 仓库 中（下面会解释这么做的好处）
6. 获取：（分布式管理）
   • 向服务器申请获取自己没有的 修订
7. 合并：
   • 将指定的 修订 合并到 编辑区 的版本中
   • 当其他人比你向服务器 提交 的早的时候，需要将他人的修改 获取，然后融合到自己的修改中再 提交，否则会弄丢别人的工作成果
   • 合并 会直接作用到 编辑区，一旦失误就会彻底丢失，所以一定要仔细
8. 更新： (集中式管理)
   • 向服务器申请获取自己没有的 修订
   • 直接融合到 编辑区，这里相当于 获取 加 合并

2.操作顺序（操作流程）

• 集中式管理：
  • 检出 ——> 编辑 ——> 标记 ——> 更新 ——> 合并（自己先提交则省略）——> 提交
• 分布式管理：
  • 克隆 ——> 编辑 ——> 添加 ——> 获取 ——> 合并（自己先提交则省略）——> 提交 ——> 推送

3.协作方式（协同流程）

• 集中式工作流
  • 工作流程
    1. 创建中心 仓库
    2. 开发人员A,B从此 仓库 检出 最新 修订，做出修改
    3. 开发人员A推送修改
    4. 开发人员B推送修改之前，先将A的工作合并进来，这样才不会弄丢A的工作
    5. 开发人员B推送修改
    6. 如此循环递推
  • 支持方式
    1. 集中式管理
    2. 分布式管理
  • 用途
    1. 安全的管理 仓库：因为是唯一的中心仓库，可以分别设定每个开发人员的权限（比如不同文件夹的读，写权限）
       • 这种模式应用广泛，大多数人都很熟悉也很习惯。可以很好的工作在单个的项目上

• 集成管理工作流
  • 支持方式
    1. 分布式管理
       • 分布式支持多个远程 仓库 存在，使得这样一种工作流成为可能
       • 每个开发者拥有自己的写权限和其他所有人 仓库 的读权限
       • 这种情况下通常会有个代表‘官方’项目的权威的仓库，要为这个项目做贡献，要先从这个项目克隆一份自己的公开仓库，然后推送自己的修改
  • 工作流程
    1. 项目维护者（集成管理者）将项目 推送 到远端的 官方仓库（开放权限）
    2. 贡献者（开发者）克隆 此仓库，进行修改
    3. 贡献者（开发者）将数据 推送 到自己的 远端仓库（开放权限）
    4. 贡献者（开发者）给通知维护者，请求拉取自己的更新
    5. 项目维护者（集成管理者）在自己本的仓库中，将贡献者的仓库加为远程仓库然后合并修改
    6. 项目维护者（集成管理者）将合并后的修改 推送 到 官方仓库
  • 用途
    1. 这是GitHub和Gitlab等常用的工作流程。人们可以容易的将某个项目派生为自己的公开仓库，推送自己的修改，让所有人可见。
       • 这样做的优点是你可以持续地工作，而主仓库的维护者可以随时拉取你的修改
       • 贡献者不必等待维护者处理完提交的更新，每一方都可以按自己的节奏工作。（多人并行可以最优化减少相互阻塞等待的时间）
       • 对于协作的成果，可以审核后添加，实际更加安全和稳定

• 司令官与副官工作流
  • 支持方式
    1. 分布式管理
       • 分布式支持多个远程 仓库 存在，使得这样一种工作流成为可能
       • 这其实是多仓库工作流程的变种
  • 工作流程
    1. 普通开发者克隆 官方仓库 到自己的 远端仓库，并在向这个仓库提交修改
    2. 副官将普通开发者的 远端仓库 合并到自己的 远端仓库（先合并到本机，在推送到远端）
    3. 司令管将副官的 远端仓库 合并到本机，然后推送到官方仓库
    4. 其他人以 官方仓库 为基础从新更新自己的 远端仓库
  • 用途
    1. 这其实是多仓库工作流的变种。一般拥有数百位协作开发者的超大型项目才会用到这样的工作方式，例如著名的Linux内核项目
    2. 被称为副官(lieutenant)的各个集成管理者分别负责集成项目中的特定部分。所有这些副官头上还有称为司令管（dictator）的总集成管理者负责统筹
    3. 这种工作流程并不常用，只有当项目极为庞杂，或者需要多级别管理，才会体现出优势。
    4. 项目总负责人（司令官）可以把大量分散的集成工作给不同的小组负责人分别处理，然后在不同时刻将大块的代码子集系统统筹起来，用于之后的整合

三.如何选择

---

1. 两种方式的优缺点

• 集中式工作流
  • 优点
  1. 保密：对于公司，可能需要整体项目的保密，每个人都只了解自己的工作内容
  2. 安全：可以对不同开发人员分配对于不同文件夹，不同读写的访问权限
  3. 简单：理解相对简单，对于大多数人做好初始工作后，大部分人就只需记住更新，合并，提交三件事。
  • 缺点
  1. 必须链接服务器才能进行备份，一旦失去网络无法备份
  2. 由于本地没有备份，只有编辑中的版本，一旦更新需要合并他人的版本时，只要失误就会丢失编辑中的成过。
  3. 不能自由的建立分支，因为是集中式大多数人没有权限建立分支，只能大家一起工作在一条分支上，相互阻塞的开发
• 分布式工作流
  • 优点
  1. 可以离线完全自由的工作
  2. 可以安全的合并，因为有众多手段可以在合并之前进行备份（可以本地提交，可以暂存（编辑中版本，待提交版本是独立的）。。。），在失误后也有手段一定程度地追回
  3. 可以自由的并行开发，因为可以随意建立分支，并且支持多个远端服务器，这使从一个远端获取合并，然后推送到另一个远端成为可能
  4. 可以进行大型项目，数百人的，有效自由地协同开发（Git的前身BitKeeper是开发Linux核心的专有版本管理系统（2002-2005））
  • 缺点
  1. 开放性，协同人员可以获得全部的版本库
  2. 相对复杂性，基础使用需要增加两步，灵活使用也需要额外了解些流程和指令

2. 使用场景

• 集中式工作流
  1. 需要保密的产品项目
  2. 产品线相对单一，或功能性关联紧密的产品项目
• 分布式工作流
  1. 开源项目（需要工作时间相对独立自由，可以开放版本）
  2. 大型项目（协同人员众多，需要分级审核）
  3. 产品线众多，功能相对独立（比如linux的音频，文件存储，设备驱动都可以相对独立进行不同分支的开发）

---

参考：
【1】Git 官方手册: https://www.git-scm.com/book/zh/v2
【2】Subversion 官方手册: http://svnbook.red-bean.com
前文链接：
【1】版本管理核心理解（一）：用途与用户