• 分支管理


    软件的版本控制以及分支管理贯穿于整个软件产品的生命周期,日常的项目管理对于开发团队能否有节奏且顺利的交付软件也很重要。 本文档将阐述不同的分支管理模型,以及它们的优缺点和使用的场景。

    分支管理规范

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

    GitFlow

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

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

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

    优点:

    缺点:

    GitHubFlow

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

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

    GitLabFlow

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

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

    分支命名规约

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

    提交命名规约

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

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

    常见的操作类型有: