Gitlab flow 是 Git flow 与 Github flow 的综合,它吸取了两者的优点,既有适应不同开发环境的弹性,又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。

    Gitlab flow 的最大原则叫做”上游优先”(upsteam first),即只存在一个主分支master,它是所有其他分支的”上游”。只有上游分支采纳的代码变化,才能应用到其他分支。

    基于环境
    对于”持续发布”的项目,它建议在master分支以外,再建立不同的环境分支。比如,”开发环境”的分支是master,”预发环境”的分支是pre-production,”生产环境”的分支是production。

    开发分支是预发分支的”上游”,预发分支又是生产分支的”上游”。代码的变化,必须由”上游”向”下游”发展。比如,生产环境出现了bug,这时就要新建一个功能分支,先把它合并到master,确认没有问题,再cherry-pick到pre-production,这一步也没有问题,才进入production。

    只有紧急情况,才允许跳过上游,直接合并到下游分支。
    image.png

    基于发布计划

    对于”版本发布”的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支,比如2-3-stable、2-4-stable等等。
    以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号
    image.png

    引入了“上游优先”(upsteam first)的原则。只存在一个主分支master,它是所有其他分支的”上游”。只有上游分支采纳的代码变化,才能应用到其他分支。版本发布”的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支。使用gitlab建立group project,可以将成员全部添加进小组中,每个人的提交都以分支合并进master分支的方式进行,我们可以将master设置成protected branch,这样就做到了强制代码review的机制,利于提升代码的质量。Issue 用于 Bug追踪和需求管理。建议先新建 Issue,再新建对应的功能分支