• Git代码版本控制流程


    我们的项目使用Git作为代码仓库、和版本控制工具。

    Git有几种Workflow,来管理代码版本变更流程,我们采用Gitflow Workflow流程。

    Gitflow Workflow,采用了master、develop、release、feature、hotfix等几个分支。master、develop分支的生命周期是永久的,release、feature、hotfix分支都是辅助分支,其生命周期是短暂的。

    各个分支的作用及意义,见下。 

    master分支

    master分支用于保存官方发布历史,与线上的版本一致。要确保任何时候从master分支都可以拿到处于可发布状态的代码。

    一个工程只有一个master分支,创建Git工程后自动创建,生命周期为永久。

    跟master分支打交道的分支有release分支、hotfix分支:

    • 测试通过后,“配置管理员”(以下简称为“配管”)将release分支合并到master分支。
    • 线上紧急修复后,“配管”将hotfix分支合并回master分支。

    release分支合并到master分支后,需要在master分支上打Tag(记录里程碑),标记官方发布的版本号。

    版本号的命名规则

    命名规则:vx.y.z

    • x: 大版本号,有重大功能发布时升位。
    • y:中版本号,增加新功能或功能优化改进时升位。
    • z:小版本号,有hotfix时升位。

    “配管”负责在master分支上打Tag。

    develop分支

    develop是开发集成的分支,所有开发完成的代码提交到此分支。功能累积到一定程度或者周期性发布需要提测时,从此分支迁出代码到release分支,进行测试。要确保任何时候都可以从develop分支拿到最新开发进展的代码。

    一个工程只有一个develop分支,最初由“配管”创建,生命周期为永久。

    跟develop分支打交道的分支有release分支、hotfix分支、feature分支:

    • “开发主管”提测时,“配管”从develop分支迁出代码到release分支。
    • release分支测试通过后,“配管”将release分支合并回develop分支。
    • 线上紧急修复后,“配管”将hotfix分支合并到develop分支。
    • 功能开发完成后,“开发主管”(需要多人协作开发的feature)或各个开发(独立开发的feature)将feature分支合并到develop分支。

    release分支

    release是测试分支,用于测试某个待发布的版本。从develop分支迁出代码到release分支,冻结代码(除了修改bug),进行测试。测试通过后合并到master分支,正式发布。

    release分支使得待发布版本的测试与新版本的开发活动可以并行,互不干扰。

    一个工程有多个release分支,一个待测试的、准备发布的版本一个分支。release分支的生命周期不是永久的,最初起源于develop分支,最终归于master和develop分支。提测时,“配管”创建一个release分支;测试通过、合并到master分支及develop分支后,“配管”删除该分支。

    跟release分支打交道的分支有develop分支、master分支:

    • “开发主管”提测时,“配管”从develop分支迁出代码、创建一个release分支。
    • release分支测试通过后,“配管”将release分支合并到master分支,同时合并回develop分支。

    release分支的命名规则

    命名规则:release_x.y.z

    x、y、z的意义,同master的Tag。因为release分支一般用于发布新功能或功能优化改进,所以x、y会有升位,z取0。

    测试、开发修改bug,都是在release分支上进行。在此期间,应严禁新功能的代码并入release分支,应合并到develop分支。

    feature分支

    feature分支是各个功能的开发分支,开发完成后合并到develop分支。

    feature分支使得多个人可以并行开发,互不干扰。

    一个工程有多个feature分支,一个feature一个分支。feature分支的生命周期不是永久的,最初起源于develop分支,最终也归于develop分支。开始开发一个新功能时,由“开发主管”或开发自己创建一个feature分支;功能开发完成、合并到develop分支后,“开发主管”或开发自己删除该分支。

    跟feature分支打交道的分支只有develop分支:

    • 对于需要多人协作开发的feature:“开发主管”从develop分支迁出代码、创建一个feature分支,然后通知给需要协作的各个开发;各个开发在此分支上提交代码。各个开发的代码都提交后,“开发主管”将该feature分支合并到develop分支,然后删除该分支。
    • 对于不需协作、开发可独立完成的feature:可以由开发自己从develop分支迁出代码、创建一个feature分支;开发完成后,开发自己将该feature分支合并到develop分支,然后删除该分支。

    feature分支的命名规则

    命名规则:feature_xxx
    xxx为功能的名称,如notification(通知)、circle(圈子)等。

    hotfix分支

    hotfix分支用于紧急修复线上的bug。

    hotfix分支使得线上bug的紧急修复,与待发布版本的测试、以及新版本的开发活动可以并行,互不干扰。

    一个工程有多个hotfix分支,一次hotfix创建一个分支。hotfix分支的生命周期不是永久的,最初起源于master分支,最终归于master和develop分支。提出hotfix时,“配管”创建一个hotfix分支;bug修改完成、合并回master分支以及develop分支后,“配管”删除该分支。

    跟hotfix分支打交道的分支有master分支、develop分支:

      • 需要紧急修复线上bug时,“配管”从master分支的某个Tag(一般是最新的)迁出代码、创建一个hotfix分支。
      • bug修改完成、测试通过后,“配管”将该hotfix分支合并回master分支,同时合并到develop分支。 

    hotfix分支的命名规则

    命名规则:hotfix_yyyymmmdd

    yyyymmdd为提出hotfix的日期,一般情况下hotfix的bug必须当天修复、发布。

     hotfix分支合并回master分支后,需要在master分支上打一个Tag,标记当前版本,小版本号升位。

     具体到一个工程中,各个阶段的具体流程为:

    项目启动

    准备开发环境

    测试流程

     发布流程:

    hotfix流程:

  • 相关阅读:
    [HNOI2010]CITY 城市建设

    [HNOI2011]数学作业
    [NOI2012]美食节
    [HEOI2014]大工程
    [HEOI2013]ALO(待更)
    [HEOI2016/TJOI2016]序列
    贪食蛇(未完待续)
    [HEOI2016/TJOI2016]字符串
    bzoj 2437[Noi2011]兔兔与蛋蛋 黑白染色二分图+博弈+匈牙利新姿势
  • 原文地址:https://www.cnblogs.com/fangsmile/p/11535302.html
Copyright © 2020-2023  润新知