代码分支管理

大家好，我是rainbowzhou。

大家或许遇到过以下情况：

• 已修复过的bug，某次更新后又复现；
• 某些问题仅在UAT环境上出现，测试环境却没有；
• 同一个项目的不同版本，代码相互覆盖，导致测试进度受阻…
  上述情况最有可能的原因就是代码分支管理混乱所致。那么今天就和大家重温一下，代码分支策略有关的知识。

版本控制系统

提到版本控制系统，大家脑海里肯定会想到SVN或Git。那么大家再想想它们属于哪一种版本控制系统呢？其实根据版本控制系统的运作方式，目前主流版本管理系统被划分为集中式版本控制系统和分布式版本控制系统两种类型。

集中式版本控制系统

Subversion 简称SVN，是集中式版本控制系统的典型代表。版本控制系统的出现，解决了多人如何进行协同修改代码的问题。这类版本控制系统，都有一个单一的集中管理的版本控制管理服务器，保存所有文件的历史修订版本记录。团队成员之间的代码交换必须通过客户端连接到这台服务器，获取自己想要的文件。每个人如果想要获取其他人最新提交的修订记录，就必须从集中式版本控制系统中获得。

集中式版本控制系统有两点劣势：

1. 网络不佳的情况下，同步大量文件时会经常失败；
2. 集中式版本控制系统有单点故障的风险。

分布式版本控制系统

Git是目前主流的分布式版本控制系统。起源于Linus Torvalds 为了帮助管理Linux内核开发而开发的一个开源的版本控制软件。它与集中式版本控制系统的区别在于多个服务器共存，每个人的节点都是一个代码仓库，所有的节点都是平等的。在团队协作过程中，通常会指定某个节点作为团队的中央服务器。

分布式版本控制系统的优势：

1. 分布式版本控制系统提交操作都是在本地进行而无须经过服务器，因此提交速度更快。仅当需要向其他人或远程服务器做文件提交或同步时，才通过网络将其推送到远程仓库或从远程仓库拉取。
2. 分布式版本控制系统避免了单点故障的风险。

常见分支开发模式

按照新功能开发以及版本发布所用的分支进行分类，可将基于版本控制系统的开发模型分为3类：

1. 主干开发，主干发布；
2. 主干开发，分支发布；
3. 分支开发，主干发布。

主干开发，主干发布

含义：主干开发，主干发布就是工程师向主干上提交代码，并用主干代码进行软件交付。
特点：

• 优势：分支方式简单，管理工作量较少；
• 不足：会有等待时间，存在一定的资源浪费；若高频交付，可能存在未完成功能的代码。

主干开发，分支发布

含义：开发人员将写好的代码提交到主干，当新版本功能全部开发完的时候，从主干上拉出一个新的分支，并在这个新分支上进行集成测试，修复bug，进行质量打磨。当质量达标后，就对外发布版本。
特点：

• 优势：与将要发布的新功能无关的人员可以持续工作在开发主干上，不受版本发布的影响。新发布的版本出现缺陷后，可以直接在其自己的版本发布分支上进行修复。即使主干代码发生了变化，该分支也不会受到影响。
• 不足：主干代码通常只能针对下一个新发布版本的功能开发；若发布分支的数量不加约束，并且分支周期较长，可能出现分支地狱倾向。

分支开发，主干发布

含义：主干上拉出分支，并在分支上开发软件新功能或修复缺陷，当某个分支上的功能开发完成后对外发布版本时，才合入主干，在主干上进行缺陷修复，质量达标后，再将主干代码打包并发布。
特点：

• 优势：分支合并钱，每个分支间的开发活动互不影响；团队可以自由选择发布某个分支的特性；若新版本出现缺陷，可以直接在主干上进行修复，无须考虑其他分支
• 不足：推迟发现代码冲突的时间，不利于及时进行代码的重构.

以上，有任何想法都欢迎大家后台私信我，一起探讨交流。

如果文章对你有帮助，记得在看、点赞、转发、加关注哦！