git flow

目录——

需要了解那些内容

  1. 了解我们有那些部署环境
  2. 了解标准的git flow中每个分支的含义
  3. 了解为什么标准git flow不能管理好我们的代码
  4. 了解FastTest分支解决了我们什么问题
  5. 了解每个分支和部署环境的关系以及分支的合并时间点

我们有哪些部署环境

因为app端和桌面端的发布方式不太一样,所以不在讨论范围内。这里只以web端为例。

为什么讲解git flow需要先了解部署环境?只有当分支管理对生产环境或其它重要环境产生重大影响的时候,我们才会真正去重视我们的代码版本管理情况。因此将环境的部署活动和代码版本管理规范联系到一起才有意义。

下图就是我们文档协同的所有部署环境:

 git flow

本机环境:主要是程序员的编码环境。

开发环境:开发环境主要用于预研活动。

联调环境:用户前后端联调使用,避免程序员计算机的不稳定服务对联调方的影响。

系统测试环境(ST):交付给测试人员使用,避免联调环境的频繁发版对测试人员的影响。

压测环境(TP):压测本质上是测试的一部分,但是压测会对测试环境的服务性能有影响,避免对其它测试活动的影响,需要单独部署。

安全测试环境:安全测试环境可以在ST(含ST)以后的环境上进行。没有独立部署环境。

生产环境:为终端用户提供服务的环境,需要保持高可靠,高稳定,高性能。所以需要单独部署。

标准git flow全局图:分支模型

git flow

参见git flow的使用

 

扩展的git flow全局图:分支模型

git flow

git flow初始

  git flow初始化时会自动产生如下三个非常重要的分支

   - master

   - develop

   - FastTest:不属于标准分支,需要手动创建

  初始时三个分支的代码保持一致。禁止在这些 分支上修改代码。

Master分支:生产发布历史分支

  Master分支是在git flow 初始化时产生的。

git flow

Master分支的意义

  1. 保存了生产环境的每次成功发版。

  2. 当develop被污染时,为新的develop分支提供基础代码。

  什么是成功发版?成功发版就是指代码不但部署成功,而且还要验证通过。为了保证Master分支的每次提交都记录的是成功版本,就需要遵守一个重要的约定“没有在生产被验证的代码禁止合并到Master分支”。

  Master上的代码只会从Release分支和Hotfix分支合并而来。禁止在Master分支直接修改代码并提交

Master分支的代码活动

  1. 禁止在Master分支直接修改代码并提交
  2. 没有在生产被验证的代码禁止合并到Master分支
  3. Master上的代码只会从Release分支和Hotfix分支合并而来
  4. 每次合并到Master后都需要打一个标签TAG

Master分支的部署活动

   1. 生产回滚:当生产需要回滚时需要将Master上的某个TAG恢复到生产。

   2. 发布到其它环境:为了验证生产环境的代码或其它要求可以把master代码发布到别的环境。

Master分支的命名规范

  无,Master需要打tag。

Develop分支:功能集成分支

  Develop分支也是在git flow 初始化时产生的。

Develop分支的意义

  1. 保存下一次Release的代码。

  2. 为新功能开发提供基础代码。

  注意:Develop分支保存的是下一次Release的代码,并不是开发完成的代码,更加不是需要联调的代码。为了保正这一点,就需要遵守另一个重要的约定“没有被确认需要Release的代码不许合并到Develop分支”。

Develop分支的代码活动

git flow

  1. Feature分支开发完成后并被确认需要Release的时候可以合并到Develop。

  2. Release分支合并到Master的时候需要合并到Develop

  3. Hotfix分支合并到Master的时候需要合并到Develop

  禁止在Develop分支上直接修改代码并提交。

Develop分支的部署活动

   1. 系统测试环境(ST):每次有新的Feature合并到Develop时都应该重新部署系统测试环境。部署ST环境时需要通知测试,避免打乱了测试在ST的回归测试。

Develop分支的命名规范

无,每次合并提交需要说明提交了什么功能,能协商jira编码或地址最好。

FastTest分支:快速验证分支

    FastTest不属于标准分支模型中的分支,所以使用工具完成git flow 初始化时是没有这个分支,需要手动创建。

FastTest分支的意义

git flow

    1.让任何在开发中的功能都可以发布到开发环境或联调环境,而不用担心该功能是否需要上线。

FastTest分支的代码活动

    FastTest的代码都是通过Feature合并而来,由于任何功能都可以合并到FastTest,所以对FastTest做如下说明和约定:

     1.  禁止在FastTest分支上修改代码

     2.  禁止将FastTest合并到其它分支:前两点都是因为FastTest是极容易被污染的分支,它上面有开发中的、不会被发版本以及一些预研功能。

     3.  如果FastTest分支已经被污染到不可用状态,删除后重新从Develop分支拉取,并重新将不在Develop上的Feature分支合并到新的FastTest.完成FastTest的重生。

FastTest分支的部署活动

  1. 联调环境:可以*发版。

FastTest分支的明明规范

无,重生后保持同名。

Feature分支:功能分支

  功能分支是code的开始。是一个独立可运行的功能,通常就代表了一个bug或一个独立任务或一个stroy.

Feature分支的协作问题

  1. 功能小的时候由一个开发员独有,如修复文件名称长度校验错误。

  2. 功能较大的时候,由多个开发员一起协作,如新增一个图纸管理模块。

Feature分支的拉取依据

  1. 新模块的放同一个分支,如新增图纸管理模块。

  2.  耦合强,相互依赖的功能放同一个分支。

  3. 线性依赖的功能,如A依赖B.可以分开两个分支,开发过程中总是将B合并到A。也可以拉一个分支方便协同。

  3. 明显能判断出功能间是独立的的功能,放不同的分支。方便独立发布。

Feature分支的代码活动

git flow

  1. Feature始终从Develop拉取

  2. Feature可以随意合并到FastTest分支参与联调。

  3. Feature分支在决定提测时才合并到Develop分支。如果只是预研或提前准备的功能不能合并到Develop分支

   4. Feature分支提测的bug,必须在Feature分支上修改,禁止在Develop上修改代码。

Feature分支的部署活动

  1. 本地环境

  2. 开发环境

Featrue分支的命名规范

{yyyy}/sp-{N}/{MMdd-jiraNumber-featureMark} eg:2019/sp6/0605-933-实人认证

命名后的完整路径是

origin/feature/2019/sp6/0605-933-实人认证

Release分支:发布分支

  Release分支是所有要上线的Feature都合并到Develop后拉取的,拉取Release分支后所有的bug修改都应该在Release分支上修改。这时全部成员都要齐心协力保证Release验证通过。

  因为Develop上被合并的Feature都是验证通过且需要发版的功能,所以理论上Release分支不包含任何开发未完成,测试未通过,产品经理未允许的功能。但是拉取的时候依然需要细心检查。

Release分支的意义

  1. 记录一次完整上线活动的代码。

Release分支的代码活动

git flow

  1. 从Develop拉取
  2. 直接修改代码(这是加班时刻)
  3. 验证通过后合并到Master
  4. 合并Master后合并到Develop

Release分支的部署活动

git flow

  1. 同时发布到联调环境(开发自测)、压测环境、安全环境、预发布环境(ST),并同步验证
  2. 验证通过后发布到生产环境

Release分支命名规范

{yyyy-MM-dd}-sp{N}-流水号 eg:20190605-sp6-1

命名后的完整路径是

origin/release/20190605-sp6-1

Hotfix分支:生产修复分支

如果生产环境的bug需要及时修复,那就从Master分支直接拉取Hotfix。解决完成后将Hotfix分支发布到预发布环境,然后再发布到生产。验证通过后,将Hotfix分支合并到master,并打上标签。然后再合并到Devlop分支。

Hotfix分支的意义

  记录一次线上bug的修复

Hotfix分支的代码活动

git flow

  1. 从Master拉取
  2. 直接修改代码
  3. 验证通过后合并到Master
  4. 合并Master后合并到Devlop

Hotfix分支的部署活动

git flow

  1. 发布到联调环境(开发自测)、预发布环境(测试验证)
  2. 通过后发布到GA环境

Hotfix分支的命名规范

{yyyy-MM-dd}-{mark} eg:20190605-分享链接打不开

命名后的完整路径是

origin/hotfix/20190605-分享链接打不开

迭代内的代码活动图

git flow

需要了解那些内容

  1. 了解我们有那些部署环境
  2. 了解标准的git flow中每个分支的含义
  3. 了解为什么标准git flow不能管理好我们的代码
  4. 了解FastTest分支解决了我们什么问题
  5. 了解每个分支和部署环境的关系以及分支的合并时间点

我们有哪些部署环境

因为app端和桌面端的发布方式不太一样,所以不在讨论范围内。这里只以web端为例。

为什么讲解git flow需要先了解部署环境?只有当分支管理对生产环境或其它重要环境产生重大影响的时候,我们才会真正去重视我们的代码版本管理情况。因此将环境的部署活动和代码版本管理规范联系到一起才有意义。

下图就是我们文档协同的所有部署环境:

 git flow

本机环境:主要是程序员的编码环境。

开发环境:开发环境主要用于预研活动。

联调环境:用户前后端联调使用,避免程序员计算机的不稳定服务对联调方的影响。

系统测试环境(ST):交付给测试人员使用,避免联调环境的频繁发版对测试人员的影响。

压测环境(TP):压测本质上是测试的一部分,但是压测会对测试环境的服务性能有影响,避免对其它测试活动的影响,需要单独部署。

安全测试环境:安全测试环境可以在ST(含ST)以后的环境上进行。没有独立部署环境。

生产环境:为终端用户提供服务的环境,需要保持高可靠,高稳定,高性能。所以需要单独部署。

标准git flow全局图:分支模型

git flow

参见git flow的使用

 

扩展的git flow全局图:分支模型

git flow

git flow初始

  git flow初始化时会自动产生如下三个非常重要的分支

   - master

   - develop

   - FastTest:不属于标准分支,需要手动创建

  初始时三个分支的代码保持一致。禁止在这些 分支上修改代码。

Master分支:生产发布历史分支

  Master分支是在git flow 初始化时产生的。

git flow

Master分支的意义

  1. 保存了生产环境的每次成功发版。

  2. 当develop被污染时,为新的develop分支提供基础代码。

  什么是成功发版?成功发版就是指代码不但部署成功,而且还要验证通过。为了保证Master分支的每次提交都记录的是成功版本,就需要遵守一个重要的约定“没有在生产被验证的代码禁止合并到Master分支”。

  Master上的代码只会从Release分支和Hotfix分支合并而来。禁止在Master分支直接修改代码并提交

Master分支的代码活动

  1. 禁止在Master分支直接修改代码并提交
  2. 没有在生产被验证的代码禁止合并到Master分支
  3. Master上的代码只会从Release分支和Hotfix分支合并而来
  4. 每次合并到Master后都需要打一个标签TAG

Master分支的部署活动

   1. 生产回滚:当生产需要回滚时需要将Master上的某个TAG恢复到生产。

   2. 发布到其它环境:为了验证生产环境的代码或其它要求可以把master代码发布到别的环境。

Master分支的命名规范

  无,Master需要打tag。

Develop分支:功能集成分支

  Develop分支也是在git flow 初始化时产生的。

Develop分支的意义

  1. 保存下一次Release的代码。

  2. 为新功能开发提供基础代码。

  注意:Develop分支保存的是下一次Release的代码,并不是开发完成的代码,更加不是需要联调的代码。为了保正这一点,就需要遵守另一个重要的约定“没有被确认需要Release的代码不许合并到Develop分支”。

Develop分支的代码活动

git flow

  1. Feature分支开发完成后并被确认需要Release的时候可以合并到Develop。

  2. Release分支合并到Master的时候需要合并到Develop

  3. Hotfix分支合并到Master的时候需要合并到Develop

  禁止在Develop分支上直接修改代码并提交。

Develop分支的部署活动

   1. 系统测试环境(ST):每次有新的Feature合并到Develop时都应该重新部署系统测试环境。部署ST环境时需要通知测试,避免打乱了测试在ST的回归测试。

Develop分支的命名规范

无,每次合并提交需要说明提交了什么功能,能协商jira编码或地址最好。

FastTest分支:快速验证分支

    FastTest不属于标准分支模型中的分支,所以使用工具完成git flow 初始化时是没有这个分支,需要手动创建。

FastTest分支的意义

git flow

    1.让任何在开发中的功能都可以发布到开发环境或联调环境,而不用担心该功能是否需要上线。

FastTest分支的代码活动

    FastTest的代码都是通过Feature合并而来,由于任何功能都可以合并到FastTest,所以对FastTest做如下说明和约定:

     1.  禁止在FastTest分支上修改代码

     2.  禁止将FastTest合并到其它分支:前两点都是因为FastTest是极容易被污染的分支,它上面有开发中的、不会被发版本以及一些预研功能。

     3.  如果FastTest分支已经被污染到不可用状态,删除后重新从Develop分支拉取,并重新将不在Develop上的Feature分支合并到新的FastTest.完成FastTest的重生。

FastTest分支的部署活动

  1. 联调环境:可以*发版。

FastTest分支的明明规范

无,重生后保持同名。

Feature分支:功能分支

  功能分支是code的开始。是一个独立可运行的功能,通常就代表了一个bug或一个独立任务或一个stroy.

Feature分支的协作问题

  1. 功能小的时候由一个开发员独有,如修复文件名称长度校验错误。

  2. 功能较大的时候,由多个开发员一起协作,如新增一个图纸管理模块。

Feature分支的拉取依据

  1. 新模块的放同一个分支,如新增图纸管理模块。

  2.  耦合强,相互依赖的功能放同一个分支。

  3. 线性依赖的功能,如A依赖B.可以分开两个分支,开发过程中总是将B合并到A。也可以拉一个分支方便协同。

  3. 明显能判断出功能间是独立的的功能,放不同的分支。方便独立发布。

Feature分支的代码活动

git flow

  1. Feature始终从Develop拉取

  2. Feature可以随意合并到FastTest分支参与联调。

  3. Feature分支在决定提测时才合并到Develop分支。如果只是预研或提前准备的功能不能合并到Develop分支

   4. Feature分支提测的bug,必须在Feature分支上修改,禁止在Develop上修改代码。

Feature分支的部署活动

  1. 本地环境

  2. 开发环境

Featrue分支的命名规范

{yyyy}/sp-{N}/{MMdd-jiraNumber-featureMark} eg:2019/sp6/0605-933-实人认证

命名后的完整路径是

origin/feature/2019/sp6/0605-933-实人认证

Release分支:发布分支

  Release分支是所有要上线的Feature都合并到Develop后拉取的,拉取Release分支后所有的bug修改都应该在Release分支上修改。这时全部成员都要齐心协力保证Release验证通过。

  因为Develop上被合并的Feature都是验证通过且需要发版的功能,所以理论上Release分支不包含任何开发未完成,测试未通过,产品经理未允许的功能。但是拉取的时候依然需要细心检查。

Release分支的意义

  1. 记录一次完整上线活动的代码。

Release分支的代码活动

git flow

  1. 从Develop拉取
  2. 直接修改代码(这是加班时刻)
  3. 验证通过后合并到Master
  4. 合并Master后合并到Develop

Release分支的部署活动

git flow

  1. 同时发布到联调环境(开发自测)、压测环境、安全环境、预发布环境(ST),并同步验证
  2. 验证通过后发布到生产环境

Release分支命名规范

{yyyy-MM-dd}-sp{N}-流水号 eg:20190605-sp6-1

命名后的完整路径是

origin/release/20190605-sp6-1

Hotfix分支:生产修复分支

如果生产环境的bug需要及时修复,那就从Master分支直接拉取Hotfix。解决完成后将Hotfix分支发布到预发布环境,然后再发布到生产。验证通过后,将Hotfix分支合并到master,并打上标签。然后再合并到Devlop分支。

Hotfix分支的意义

  记录一次线上bug的修复

Hotfix分支的代码活动

git flow

  1. 从Master拉取
  2. 直接修改代码
  3. 验证通过后合并到Master
  4. 合并Master后合并到Devlop

Hotfix分支的部署活动

git flow

  1. 发布到联调环境(开发自测)、预发布环境(测试验证)
  2. 通过后发布到GA环境

Hotfix分支的命名规范

{yyyy-MM-dd}-{mark} eg:20190605-分享链接打不开

命名后的完整路径是

origin/hotfix/20190605-分享链接打不开

迭代内的代码活动图

git flow

 

上一篇:Git多分支开发时 merge 合并策略


下一篇:quick-cocos2d-x-develop资源打包环境安装