目录——
- 需要了解那些内容
- 我们有哪些部署环境
- 标准git flow全局图:分支模型
- 扩展的git flow全局图:分支模型
- git flow初始
- Master分支:生产发布历史分支
- Develop分支:功能集成分支
- FastTest分支:快速验证分支
- Feature分支:功能分支
- Release分支:发布分支
- Hotfix分支:生产修复分支
- 迭代内的代码活动图
需要了解那些内容
- 了解我们有那些部署环境
- 了解标准的git flow中每个分支的含义
- 了解为什么标准git flow不能管理好我们的代码
- 了解FastTest分支解决了我们什么问题
- 了解每个分支和部署环境的关系以及分支的合并时间点
我们有哪些部署环境
因为app端和桌面端的发布方式不太一样,所以不在讨论范围内。这里只以web端为例。
为什么讲解git flow需要先了解部署环境?只有当分支管理对生产环境或其它重要环境产生重大影响的时候,我们才会真正去重视我们的代码版本管理情况。因此将环境的部署活动和代码版本管理规范联系到一起才有意义。
下图就是我们文档协同的所有部署环境:
本机环境:主要是程序员的编码环境。
开发环境:开发环境主要用于预研活动。
联调环境:用户前后端联调使用,避免程序员计算机的不稳定服务对联调方的影响。
系统测试环境(ST):交付给测试人员使用,避免联调环境的频繁发版对测试人员的影响。
压测环境(TP):压测本质上是测试的一部分,但是压测会对测试环境的服务性能有影响,避免对其它测试活动的影响,需要单独部署。
安全测试环境:安全测试环境可以在ST(含ST)以后的环境上进行。没有独立部署环境。
生产环境:为终端用户提供服务的环境,需要保持高可靠,高稳定,高性能。所以需要单独部署。
标准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分支的代码活动
- 禁止在Master分支直接修改代码并提交
- 没有在生产被验证的代码禁止合并到Master分支
- Master上的代码只会从Release分支和Hotfix分支合并而来
- 每次合并到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分支的意义
- 记录一次完整上线活动的代码。
Release分支的代码活动
- 从Develop拉取
- 直接修改代码(这是加班时刻)
- 验证通过后合并到Master
- 合并Master后合并到Develop
Release分支的部署活动
- 同时发布到联调环境(开发自测)、压测环境、安全环境、预发布环境(ST),并同步验证
- 验证通过后发布到生产环境
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分支的代码活动
- 从Master拉取
- 直接修改代码
- 验证通过后合并到Master
- 合并Master后合并到Devlop
Hotfix分支的部署活动
- 发布到联调环境(开发自测)、预发布环境(测试验证)
-
通过后发布到GA环境
Hotfix分支的命名规范
{yyyy-MM-dd}-{mark} eg:20190605-分享链接打不开
命名后的完整路径是
origin/hotfix/20190605-分享链接打不开
迭代内的代码活动图
需要了解那些内容
- 了解我们有那些部署环境
- 了解标准的git flow中每个分支的含义
- 了解为什么标准git flow不能管理好我们的代码
- 了解FastTest分支解决了我们什么问题
- 了解每个分支和部署环境的关系以及分支的合并时间点
我们有哪些部署环境
因为app端和桌面端的发布方式不太一样,所以不在讨论范围内。这里只以web端为例。
为什么讲解git flow需要先了解部署环境?只有当分支管理对生产环境或其它重要环境产生重大影响的时候,我们才会真正去重视我们的代码版本管理情况。因此将环境的部署活动和代码版本管理规范联系到一起才有意义。
下图就是我们文档协同的所有部署环境:
本机环境:主要是程序员的编码环境。
开发环境:开发环境主要用于预研活动。
联调环境:用户前后端联调使用,避免程序员计算机的不稳定服务对联调方的影响。
系统测试环境(ST):交付给测试人员使用,避免联调环境的频繁发版对测试人员的影响。
压测环境(TP):压测本质上是测试的一部分,但是压测会对测试环境的服务性能有影响,避免对其它测试活动的影响,需要单独部署。
安全测试环境:安全测试环境可以在ST(含ST)以后的环境上进行。没有独立部署环境。
生产环境:为终端用户提供服务的环境,需要保持高可靠,高稳定,高性能。所以需要单独部署。
标准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分支的代码活动
- 禁止在Master分支直接修改代码并提交
- 没有在生产被验证的代码禁止合并到Master分支
- Master上的代码只会从Release分支和Hotfix分支合并而来
- 每次合并到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分支的意义
- 记录一次完整上线活动的代码。
Release分支的代码活动
- 从Develop拉取
- 直接修改代码(这是加班时刻)
- 验证通过后合并到Master
- 合并Master后合并到Develop
Release分支的部署活动
- 同时发布到联调环境(开发自测)、压测环境、安全环境、预发布环境(ST),并同步验证
- 验证通过后发布到生产环境
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分支的代码活动
- 从Master拉取
- 直接修改代码
- 验证通过后合并到Master
- 合并Master后合并到Devlop
Hotfix分支的部署活动
- 发布到联调环境(开发自测)、预发布环境(测试验证)
-
通过后发布到GA环境
Hotfix分支的命名规范
{yyyy-MM-dd}-{mark} eg:20190605-分享链接打不开
命名后的完整路径是
origin/hotfix/20190605-分享链接打不开
迭代内的代码活动图