git flow原理

目录——

此目录的超链接我还没有搞定呢

• 需要了解那些内容
• 我们有哪些部署环境
• 标准git flow全局图：分支模型
• 扩展的git flow全局图：分支模型
• git flow初始
• Master分支：生产发布历史分支
  • Master分支的意义
  • Master分支的代码活动
  • Master分支的部署活动
  • Master分支的命名规范
• Develop分支：功能集成分支
  • Develop分支的意义
  • Develop分支的代码活动
  • Develop分支的部署活动
  • Develop分支的命名规范
• FastTest分支:快速验证分支
  • FastTest分支的意义
  • FastTest分支的代码活动
  • FastTest分支的部署活动
  • FastTest分支的明明规范
• Feature分支：功能分支
  • Feature分支的协作问题
  • Feature分支的拉取依据
  • Feature分支的代码活动
  • Feature分支的部署活动
  • Featrue分支的命名规范
• Release分支：发布分支
  • Release分支的意义
  • Release分支的代码活动
  • Release分支的部署活动
  • Release分支命名规范
• Hotfix分支：生产修复分支
  • Hotfix分支的意义
  • Hotfix分支的代码活动
  • Hotfix分支的部署活动
  • Hotfix分支的命名规范
• 迭代内的代码活动图

需要了解那些内容

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

我们有哪些部署环境

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

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

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

 

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

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

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

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

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

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

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

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

参见git flow的使用

 

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

git flow初始

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

   - master

   - develop

   - FastTest：不属于标准分支，需要手动创建

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

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

  Master分支是在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分支的代码活动

  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分支的意义

    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分支的代码活动

  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分支的代码活动

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

Release分支的部署活动

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分支的代码活动

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

Hotfix分支的部署活动

1. 发布到联调环境（开发自测）、预发布环境（测试验证）

2. 通过后发布到GA环境

Hotfix分支的命名规范

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

命名后的完整路径是

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

迭代内的代码活动图

需要了解那些内容

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

我们有哪些部署环境

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

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

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

 

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

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

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

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

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

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

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

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

参见git flow的使用

 

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

git flow初始

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

   - master

   - develop

   - FastTest：不属于标准分支，需要手动创建

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

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

  Master分支是在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分支的代码活动

  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分支的意义

    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分支的代码活动

  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分支的代码活动

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

Release分支的部署活动

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分支的代码活动

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

Hotfix分支的部署活动

1. 发布到联调环境（开发自测）、预发布环境（测试验证）

2. 通过后发布到GA环境

Hotfix分支的命名规范

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

命名后的完整路径是

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

迭代内的代码活动图