分支管理

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

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

分支管理规范

目前比较流行的分支管理模型有三个，即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。

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上。

分支命名规约

前缀含义
master主分支，可用的、稳定的、可直接发布的版本
develop开发主分支，最新的代码分支
feature-功能开发分支
bugfix-未发布bug修复分支
release-预发布分支
hotfix-已发布bug修复分支

提交命名规约

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

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

常见的操作类型有：

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

  • [FIX] 修正BUG

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

  • [ADD] 添加实现新功能

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

版本号规范

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

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

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

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

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

需求与代码关联

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

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