一 什么是git flow
就像代码需要代码规范一样,代码管理同样需要一个清晰的流程和规范。Git 作为一个源码管理系统,不可避免涉及到多人协作。协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。"工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。
Gitflow
工作流定义了一个围绕项目发布的严格分支模型。 下图能说明整个流程,该模式来自 Nvie
解释上图
- master 默认分支,只能用来包括产品代码(线上生产环境代码),不许提交,只能合并。
- develop 最新的开发状态 ,是你进行任何新的开发的基础分支。当你开始一个新的功能分支时,它将是_开发_的基础。另外,该分支也汇集所有已经完成的功能,并等待被整合到 master 分支中。develop上的代码总是从feature上合并过来的。不许提交,只能合并。
- master develop 这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中,而其他的分支,例如针对功能的分支,针对发行的分支,仅仅只是临时存在的
- feature 开发新功能的分支, 基于 develop, 完成后 merge 回 develop
- release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master
- hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop
- hotfix 分支是基于 “master” 分支。 这也是和 release 分支最明显的区别,release 分支都是基于 “develop” 分支的
二 为什么要使用git flow
- 虽然大多数团队已由svn切换到git,但代码控制方式仍然是“集中式”的,没有发挥git的强大功能。
- 在团队开发中使用版本控制系统时,商定一个统一的工作流程是至关重要的 ,git flow 有着清晰的流程和规范。
- 简单并可定义适合各自团队的flow
三 如何使用
- 初始分支,所有在Master分支上的Commit应该Tag,目前只有master角色可提交,其它角色提交不了,被保护了
-
Feature 分支 Feature分支做完后,必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支,但是我们也可以保留
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-2feature.png?version=1&modificationDate=1500637182000&api=v2)
-
Release分支
Release分支基于Develop分支创建,打完Release分之后,我们可以在这个Release分支上测试,修改Bug等。同时,其它开发人员可以基于开发新的Feature (记住:一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支) 发布Release分支时,合并Release到Master和Develop, 同时在Master分支上打个Tag记住Release版本号,然后可以删除Release分支了。
-
维护分支 Hotfix hotfix分支基于Master分支创建,开发完后需要合并回Master和Develop分支,同时在Master上打一个tag
四 命令规范
分支名称
|
规则
|
示例
|
说明
|
---|---|---|---|
master | master | 默认不可变 | |
develop | develop | 默认不可变 | |
feature | feature/* | feature/order-detail | * 为功能简述,如多个单词,中间用横线连接 |
release | release/*.rc | release/1.0.1.rc | * 为版本号, 版本号规则如下所述 |
hotfix | hotfix/* | hotfix:/1.0.1 | * 为版本号, 版本号规则如下所述 |
tag | (对应项目名,全部大写拼写)_ tag _ V * | CARNAPI_tag_V1.0.1 | * 为版本号, 版本号规则如下所述 |
版本号命名规则:
版本号命名以 [大版本号].[小版本号].[补丁号]
方式命名,其中:
- 大版本号更新表示一次里程碑开发的完成,包含了若干个 feature 的实现。
- 小版本号更新表示一个 feature 的完成。
- 补丁号更新表示发布的 feature 不变,只是修改 bug 。
举例:
- 某次发布是里程碑开发的结束,版本号为 1.0.0
- 很快,上次发布的版本发现了 bug,紧急修复,再次发布,版本号为 1.0.1
- 再次发现 bug,修复,重新发布,版本号为 1.0.2
- 几个星期后,新增了几个功能,再次发布,版本号为 1.1.0
- 几天后发现新增的功能有 bug,紧急修复,发布,版本号为 1.1.1
- 再次新增功能发布,版本号为 1.2.0
- 发现 bug,修复并发布,版本号为 1.2.1
- 再次完成一次里程碑开发,发布,版本号为 2.0.0
- ……以此类推
五 code review
由于使用了git flow ,可以将code review机制很好的结合起来,当我们合并代码的时候,是需要MR(merge request)的,这时候需要向代码审核人提交你的合并请求。具体流程可参考GitLab Flow里的最后一部分。
六 使用git flow 开发流程简述
- 从develop打feature分支,确定feature分支负责人(今后这个分支分出去的其它分支都由他负责,他负责MR时的代码评审)。
- 在feature分支上开发,如其它同事的其它feature分支合并回了develop,会要求通过大家。如需要(一般是公共影响部分)在你自己的feature分支上合并develop上的代码。
- 开发完feature分支代码,提交合并请求,合并至develop,由代码评审人评审通过后合并。合并完成后,删除feature分支。
- 提测前,从develop中打出release分支给测试使用,如测试通过不需要修改,则合并回master和develop并删除;如有问题,可以在release分支上修改,修改完毕后,再合并回master,develop,并删除release分支。
- 上线前,在maser分支上打出tag
- 线上有bug,从master打出hotfix分支修复,完成后,合并回 master和 develop ,删除hotfix分支。
一 什么是git flow
就像代码需要代码规范一样,代码管理同样需要一个清晰的流程和规范。Git 作为一个源码管理系统,不可避免涉及到多人协作。协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。"工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。
Gitflow
工作流定义了一个围绕项目发布的严格分支模型。 下图能说明整个流程,该模式来自 Nvie
解释上图
- master 默认分支,只能用来包括产品代码(线上生产环境代码),不许提交,只能合并。
- develop 最新的开发状态 ,是你进行任何新的开发的基础分支。当你开始一个新的功能分支时,它将是_开发_的基础。另外,该分支也汇集所有已经完成的功能,并等待被整合到 master 分支中。develop上的代码总是从feature上合并过来的。不许提交,只能合并。
- master develop 这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中,而其他的分支,例如针对功能的分支,针对发行的分支,仅仅只是临时存在的
- feature 开发新功能的分支, 基于 develop, 完成后 merge 回 develop
- release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master
- hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop
- hotfix 分支是基于 “master” 分支。 这也是和 release 分支最明显的区别,release 分支都是基于 “develop” 分支的
二 为什么要使用git flow
- 虽然大多数团队已由svn切换到git,但代码控制方式仍然是“集中式”的,没有发挥git的强大功能。
- 在团队开发中使用版本控制系统时,商定一个统一的工作流程是至关重要的 ,git flow 有着清晰的流程和规范。
- 简单并可定义适合各自团队的flow
三 如何使用
- 初始分支,所有在Master分支上的Commit应该Tag,目前只有master角色可提交,其它角色提交不了,被保护了
-
Feature 分支 Feature分支做完后,必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支,但是我们也可以保留
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-2feature.png?version=1&modificationDate=1500637182000&api=v2)
-
Release分支
Release分支基于Develop分支创建,打完Release分之后,我们可以在这个Release分支上测试,修改Bug等。同时,其它开发人员可以基于开发新的Feature (记住:一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支) 发布Release分支时,合并Release到Master和Develop, 同时在Master分支上打个Tag记住Release版本号,然后可以删除Release分支了。
-
维护分支 Hotfix hotfix分支基于Master分支创建,开发完后需要合并回Master和Develop分支,同时在Master上打一个tag
四 命令规范
分支名称
|
规则
|
示例
|
说明
|
---|---|---|---|
master | master | 默认不可变 | |
develop | develop | 默认不可变 | |
feature | feature/* | feature/order-detail | * 为功能简述,如多个单词,中间用横线连接 |
release | release/*.rc | release/1.0.1.rc | * 为版本号, 版本号规则如下所述 |
hotfix | hotfix/* | hotfix:/1.0.1 | * 为版本号, 版本号规则如下所述 |
tag | (对应项目名,全部大写拼写)_ tag _ V * | CARNAPI_tag_V1.0.1 | * 为版本号, 版本号规则如下所述 |
版本号命名规则:
版本号命名以 [大版本号].[小版本号].[补丁号]
方式命名,其中:
- 大版本号更新表示一次里程碑开发的完成,包含了若干个 feature 的实现。
- 小版本号更新表示一个 feature 的完成。
- 补丁号更新表示发布的 feature 不变,只是修改 bug 。
举例:
- 某次发布是里程碑开发的结束,版本号为 1.0.0
- 很快,上次发布的版本发现了 bug,紧急修复,再次发布,版本号为 1.0.1
- 再次发现 bug,修复,重新发布,版本号为 1.0.2
- 几个星期后,新增了几个功能,再次发布,版本号为 1.1.0
- 几天后发现新增的功能有 bug,紧急修复,发布,版本号为 1.1.1
- 再次新增功能发布,版本号为 1.2.0
- 发现 bug,修复并发布,版本号为 1.2.1
- 再次完成一次里程碑开发,发布,版本号为 2.0.0
- ……以此类推
五 code review
由于使用了git flow ,可以将code review机制很好的结合起来,当我们合并代码的时候,是需要MR(merge request)的,这时候需要向代码审核人提交你的合并请求。具体流程可参考GitLab Flow里的最后一部分。
六 使用git flow 开发流程简述
- 从develop打feature分支,确定feature分支负责人(今后这个分支分出去的其它分支都由他负责,他负责MR时的代码评审)。
- 在feature分支上开发,如其它同事的其它feature分支合并回了develop,会要求通过大家。如需要(一般是公共影响部分)在你自己的feature分支上合并develop上的代码。
- 开发完feature分支代码,提交合并请求,合并至develop,由代码评审人评审通过后合并。合并完成后,删除feature分支。
- 提测前,从develop中打出release分支给测试使用,如测试通过不需要修改,则合并回master和develop并删除;如有问题,可以在release分支上修改,修改完毕后,再合并回master,develop,并删除release分支。
- 上线前,在maser分支上打出tag
- 线上有bug,从master打出hotfix分支修复,完成后,合并回 master和 develop ,删除hotfix分支。