git flow 工作流程
2017-07-25 16:18
316 查看
一 什么是git flow
就像代码需要代码规范一样,代码管理同样需要一个清晰的流程和规范。Git 作为一个源码管理系统,不可避免涉及到多人协作。协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。"工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。
![](http://wiki.10101111.com/download/attachments/136348797/git-model@2x.png?version=1&modificationDate=1500634582000&api=v2)
解释上图
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角色可提交,其它角色提交不了,被保护了
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-1historical.png?version=1&modificationDate=1500637108000&api=v2)
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-2feature.png?version=1&modificationDate=1500637182000&api=v2)
Release分支基于Develop分支创建,打完Release分之后,我们可以在这个Release分支上测试,修改Bug等。同时,其它开发人员可以基于开发新的Feature (记住:一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支) 发布Release分支时,合并Release到Master和Develop,
同时在Master分支上打个Tag记住Release版本号,然后可以删除Release分支了。
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-3release.png?version=1&modificationDate=1500637706000&api=v2)
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-4maintenance.png?version=1&modificationDate=1500637790000&api=v2)
四 命令规范
版本号命名规则:
版本号命名以
大版本号更新表示一次里程碑开发的完成,包含了若干个 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",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。
![](http://wiki.10101111.com/download/attachments/136348797/git-model@2x.png?version=1&modificationDate=1500634582000&api=v2)
解释上图
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角色可提交,其它角色提交不了,被保护了
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-1historical.png?version=1&modificationDate=1500637108000&api=v2)
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-2feature.png?version=1&modificationDate=1500637182000&api=v2)
Release分支基于Develop分支创建,打完Release分之后,我们可以在这个Release分支上测试,修改Bug等。同时,其它开发人员可以基于开发新的Feature (记住:一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支) 发布Release分支时,合并Release到Master和Develop,
同时在Master分支上打个Tag记住Release版本号,然后可以删除Release分支了。
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-3release.png?version=1&modificationDate=1500637706000&api=v2)
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-4maintenance.png?version=1&modificationDate=1500637790000&api=v2)
四 命令规范
版本号命名规则:
版本号命名以
大版本号更新表示一次里程碑开发的完成,包含了若干个 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 作为一个源码管理系统,不可避免涉及到多人协作。协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。"工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。
Gitflow工作流定义了一个围绕项目发布的严格分支模型。 下图能说明整个流程,该模式来自 Nvie
![](http://wiki.10101111.com/download/attachments/136348797/git-model@2x.png?version=1&modificationDate=1500634582000&api=v2)
解释上图
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角色可提交,其它角色提交不了,被保护了
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-1historical.png?version=1&modificationDate=1500637108000&api=v2)
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分支了。
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-3release.png?version=1&modificationDate=1500637706000&api=v2)
维护分支 Hotfix hotfix分支基于Master分支创建,开发完后需要合并回Master和Develop分支,同时在Master上打一个tag
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-4maintenance.png?version=1&modificationDate=1500637790000&api=v2)
四 命令规范
分支名称 | 规则 | 示例 | 说明 |
---|---|---|---|
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
![](http://wiki.10101111.com/download/attachments/136348797/git-model@2x.png?version=1&modificationDate=1500634582000&api=v2)
解释上图
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角色可提交,其它角色提交不了,被保护了
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-1historical.png?version=1&modificationDate=1500637108000&api=v2)
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分支了。
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-3release.png?version=1&modificationDate=1500637706000&api=v2)
维护分支 Hotfix hotfix分支基于Master分支创建,开发完后需要合并回Master和Develop分支,同时在Master上打一个tag
![](http://wiki.10101111.com/download/attachments/136348797/o_git-workflow-release-cycle-4maintenance.png?version=1&modificationDate=1500637790000&api=v2)
四 命令规范
分支名称 | 规则 | 示例 | 说明 |
---|---|---|---|
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分支。
相关文章推荐
- Gitflow工作流程
- 转:git-flow 的工作流程
- [GIT] Git 工作流程(Git flow, Github flow flow, Git lab flow)
- Gitflow工作流程
- Gitflow工作流程
- Git flow基本工作流程介绍
- Gitflow工作流程
- git 工作流程
- git - 简明指南(工作流程)
- Git flow 的流程
- 理解Git的工作流程
- git工作流程、Git 工作区、暂存区和版本库
- Git手册 - 工作流程
- GitHub超详细图文攻略 - Git客户端下载安装 GitHub提交修改源码工作流程 Git分支 标签 过滤 Git版本工作流
- SourceTree 实现 git flow 流程
- Git工作流程
- Git的工作模式和工作流程
- Git 系列之一:版本控制的概念、分布式、Git 简介及其工作流程
- 使用Git工作的一般流程
- Git 工作流程