分支管理

软件的版本控制以及分支管理贯穿于整个软件产品的生命周期，日常的项目管理对于开发团队能否有节奏且顺利的交付软件也很重要。本分支管理和版本控制规范主要分为3个部分，即分支管理规范、版本号规范、需求与代码关联。其中，将阐述不同的分支管理模型，以及它们的优缺点和使用的场景；描述版本号控制方式——语义化版本；以及将需求与代码管理的必要性等。

分支管理规范

目前比较流行的分支管理模型有三个，即GitFlow、GitLabFlow、GitHubFlow。下面将介绍这三种分支模型的原理，使用场景和优缺点等。

GitFlow

GitFlow 是最早诞生并得到广泛应用的一种工作流程。

该模型中存在两种长期分支：master 和 develop。 master中存放对外发布的版本，只有稳定的发布版本才会合并到master中。 develop用于日常开发，存放最新的开发版本。

也存在三种临时分支：feature, hotfix, release。

• feature分支是为了开发某个特定功能，从develop分支中切出，开发完成后合并到develop分支中。
• hotfix分支是修复发布后发现的Bug的分支，从master分支中切出，修补完成后再合并到master和develop分支。
• release分支指发布稳定版本前使用的预发布分支，从develop分支中切出，预发布完成后，合并到develop和master分支中。

优点：

• feature 分支使开发代码隔离，可以独立的完成开发、构建、测试
• feature 分支开发周期长于release时，可避免未完成的feature进入生产环境

缺点：

• 无法支持持续发布。
• 过于复杂的分支管理，加重了开发者的负担，使开发者不能专注开发。

GitHubFlow

GitHubFlow分支模型只存在一个master主分支，日常开发都合并至master，永远保持其为最新的代码且随时可发布的。

• 在需要添加或修改代码时， 基于master创建分支，提交修改。
• 创建Pull Request，所有人讨论和审查你的代码。
• 然后部署到生产环境中进行验证。
• 待验证通过后合并到master分支中。

这个分支模型的优势在于简洁易理解，将master作为核心的分支，代码更新持续集成至master上。根据目前收集到的反应来看，得到了更多的好评，认为GitHubFlow分支模型更加轻便快捷。

GitLabFlow

GitLabFlow 是GitFlow和GitHubFlow的结合,它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。

该模型采取上游优先的原则，即只存在一个master主分支，它是所以分支的上游。只有上游分支采纳的变动才能应用到其他分支。

• 对于持续发布的项目，建议在master之外再建立对应的环境分支，如预生产环境pre-production，生产环境production。

• 对于版本发布的项目，建议基于master创建稳定版本对应的分支，如stable-1，stable-2。

HZERO

HZERO中采取了GitFlow的模式，并提供多种分支类型。

分支命名规约

提交命名规约

除了分支的名称需要规范，提交的命名也同样如此。猪齿鱼并没有把这个规则固化到系统中，需要团队共同遵守。

格式为：[操作类型]操作对象名称，如[ADD]readme，代表增加了readme描述文件。

常见的操作类型有：

• [IMP] 提升改善正在开发或者已经实现的功能

• [FIX] 修正BUG

• [REF] 重构一个功能，对功能重写

• [ADD] 添加实现新功能

• [REM] 删除不需要的文件

版本号规范

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

1.主版本号：当你做了不兼容的 API 修改。

2.次版本号：当你做了向下兼容的功能性新增。

3.修订号：当你做了向下兼容的问题修正。

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

需求与代码关联

在 HZERO 中，可以通过 Issue 创建分支，或者创建分支时选择关联的 Issue，通过这种方式将需求与代码进行关联。

这样，我们可以追溯到一个用户故事对应了哪些分支，哪几个提交， 甚至出现了一些 BUG，可以找到是哪个分支提交的，当初为了发布XXX新的需求，不仅如此，我们通过需求与代码分支关连，能够查看到哪些需求已经部署到了测试环境，那些需求已经部署到了正式环境，以及从业务到代码的整个链条的统计分析。