分支管理

此规范是Choerodon社区在研发和实施的过程中经验的总结，并且将部分内容固化到Choerodon系统中，希望能够给广大读者提供一个参考和借鉴，俗话说，“百密一疏”，其中如有不正确的地方，烦请不吝指正。

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

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

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

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

• feature分支是为了开发某个特定功能，从develop分支中切出，开发完成后合并到develop分支中。

• release分支指发布稳定版本前使用的预发布分支，从develop分支中切出，预发布完成后，合并到和master分支中。
  优点：

• feature 分支使开发代码隔离，可以独立的完成开发、构建、测试

• feature 分支开发周期长于release时，可避免未完成的feature进入生产环境
  缺点：

• 无法支持持续发布。

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

GitHubFlow

• 在需要添加或修改代码时， 基于master创建分支，提交修改。
• 创建Pull Request，所有人讨论和审查你的代码。
• 然后部署到生产环境中进行验证。
• 待验证通过后合并到master分支中。
  这个分支模型的优势在于简洁易理解，将master作为核心的分支，代码更新持续集成至master上。根据目前收集到的反应来看，得到了更多的好评，认为GitHubFlow分支模型更加轻便快捷。

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

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

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

Choerodon

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

• 在领到日常开发任务时，基于master创建feature特性开发分支，提交代码后，合并至master并删除feature。
• 在领到修复故障的任务时，基于master创建bugfix故障修补分支，提交代码后，合并至master并删除bugfix。
• 需要发布时，同样需要基于master创建release，生成的应用版本部署在UAT测试环境进行测试，若需要修改则提交至release。
• 产品上线后发现故障需要紧急进行热修复时，则基于tag创建hotfix，将修复的代码提交至hotfix；部署该分支上的版本通过验收后，基于hotfix打出热修版本的tag，如0.8.1。
• 由于新版本的迭代也同时进行，所以需要在hotfix上rebase master，变基至master分支最新的提交，再合并至master并删除hotfix，就可以将本次修改的提交应用至master上。

提交命名规约

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

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

常见的操作类型有：

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

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

• [ADD] 添加实现新功能

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

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

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

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

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

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

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