版本控制系统的使用目的
版本控制系统主要用于存储及追踪目录和文件的修订历史（修订操作包括 3 类：新增、修改和删除），从而让你能够回溯那些被纳入其管理范围之内的任意对象的任意一次修订。
其最本质的作用是回答 “4个W”：
- 在什么时间（
When） - 修改了什么内容（
What） - 是谁修改的（
Who） - 为什么要修改（
Why）
其中最后一个 “W” 是通过用户提交代码变更时书写提交注释的方式提供的。
集中式版本控制系统
这种类型版本控制系统的典型代表是 Subversion，简称为 SVN。
集中式版本控制系统，有一个单一的集中管理的版本控制管理服务器，保存所有文件的历史修订版本记录。团队成员之间的代码交换必须通过客户端连接到这台服务器，获取自己需要的文件。每个人如果想获得其他人最新提交的修订记录，就必须从集中式版本控制系统中获得。
集中式版本控制系统有两点劣势：
- 在网络环境不佳的情况下，同步大量文件时会经常失败。
- 具有单点故障风险。
分布式版本控制系统
目前主流的分布式版本控制系统是 Git。
分布式版本控制系统与集中式版本控制系统的区别在于多个服务器共存，每个人的节点都是一个代码仓库，所有的节点都是平等的。
分布式控制系统的特点是：提交（commit）操作都是在本地进行而无须经过服务器，因此提交速度也更快。只有当需要向其他人或远程服务器做文件提交或同步时，才通过网络将其推送到远程仓库或从远程仓库拉取。因此，即使在没有网络环境的情况下，你也可以非常愉快地频繁提交更新。当有了网络环境的时候，再推送到远程的团队代码仓库。
常见分支开发模式
- 主干开发，主干发布
- 主干开发，分支发布
- 分支开发，主干发布
分支模式的演化
- 三驾马车分支模式
Gitflow分支模式GitHubFlow分支模式
分支策略的选择
企业需要根据开发或维护的软件产品类型，结合发布频率，并考虑自身团队成员能力和基础设施水平如自动化测试程度、程序运行环境的管理水平、团队纪律性等，来确定适合自己的分支方式。
版本发布模式
版本发布的基本模式有 3 种：
- 项目制发布模式（Project Release Mode）
- 发布火车模式（Release Train Mode）
- 城际快线模式（IntercityExpress Mode）
无论哪种发布模式，都有相同的 3 个约束变量，即交付时间点（schedule）、特性数量（features）和交付质量（quality）,在团队资源相对固定的情况下,只能对其中的两个因素提出固定的要求。例如，对发布的交付时间点和交付质量提出固定要求后，那么该版本的特性数量也就相对固定了。
分支策略与发布周期的关系
通常，软件开发周期极长的 “项目制” 团队和软件发布频率极高的 “城际快线式” 团队会使用 “主干开发，主干发布” 的分支策略。而次之的团队会使用 “主干开发，分支发布” 的分支策略。它们之间的团队会使用 “分支开发、主干发布” 的分支策略。
当然，这并不是绝对的，其中会有很大的重叠部分，通常会受团队成员人数、产品架构和质量保障基础设施状况的影响。
每种分支策略都有其各自的优点和挑战。并且，它对发布频率和每次发布的效率也有较大的影响。目前的发展趋势是：软件发布频率越来越高，发布周期越来越短。
硅谷顶级互联网公司多采用 “主干开发” 或高频的GitHubFlow分支模式。一个企业到底选择哪种分支策略，需要根据团队的具体情况来决定。如果相关的配套条件（如软件架构、 人员能力和工具平台的成熟度）不足，那么，盲目提高发布频率、缩短发布周期会造成不必要的损失。
“持续交付2.0” 提倡鼓励持续集成的分支策略，因此，选择分支模式的原则有以下几条：
- 分支越少越好，最好只有一条主干；
- 分支生存周期越短越好，最好在3天以内；
- 在业务允许的前提下，发布周期越短越好；
了解更多：https://t.zsxq.com/07zEl88nH
