• 分支管理


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

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

    分支管理规范

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

    GitFlow

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

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

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

    优点:

    缺点:

    GitHubFlow

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

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

    GitLabFlow

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

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

    Choerodon

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

    分支命名规约

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

    提交命名规约

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

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

    常见的操作类型有:

    版本号规范

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

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

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

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

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

    需求与代码关联

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

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