git flow 工作流程

一  什么是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分支，但是我们也可以保留

    

        

• 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	* 为版本号， 版本号规则如下所述

    版本号命名规则：    

    版本号命名以 [大版本号].[小版本号].[补丁号] 方式命名，其中：

1. 大版本号更新表示一次里程碑开发的完成，包含了若干个 feature 的实现。
2. 小版本号更新表示一个 feature 的完成。
3. 补丁号更新表示发布的 feature 不变，只是修改 bug 。

     举例：

1. 某次发布是里程碑开发的结束，版本号为 1.0.0
2. 很快，上次发布的版本发现了 bug，紧急修复，再次发布，版本号为 1.0.1
3. 再次发现 bug，修复，重新发布，版本号为 1.0.2
4. 几个星期后，新增了几个功能，再次发布，版本号为 1.1.0
5. 几天后发现新增的功能有 bug，紧急修复，发布，版本号为 1.1.1
6. 再次新增功能发布，版本号为 1.2.0
7. 发现 bug，修复并发布，版本号为 1.2.1
8. 再次完成一次里程碑开发，发布，版本号为 2.0.0
9. ……以此类推

五 code review

     由于使用了git flow ，可以将code review机制很好的结合起来，当我们合并代码的时候，是需要MR（merge request）的，这时候需要向代码审核人提交你的合并请求。具体流程可参考GitLab Flow里的最后一部分。

 

六 使用git flow 开发流程简述

1.      从develop打feature分支，确定feature分支负责人（今后这个分支分出去的其它分支都由他负责，他负责MR时的代码评审）。
2.      在feature分支上开发，如其它同事的其它feature分支合并回了develop,会要求通过大家。如需要（一般是公共影响部分）在你自己的feature分支上合并develop上的代码。
3.      开发完feature分支代码，提交合并请求，合并至develop,由代码评审人评审通过后合并。合并完成后，删除feature分支。
4.      提测前，从develop中打出release分支给测试使用，如测试通过不需要修改，则合并回master和develop并删除；如有问题，可以在release分支上修改，修改完毕后，再合并回master,develop,并删除release分支。
5.      上线前，在maser分支上打出tag 
6.      线上有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分支，但是我们也可以保留

    

        

• 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	* 为版本号， 版本号规则如下所述

    版本号命名规则：    

    版本号命名以 [大版本号].[小版本号].[补丁号] 方式命名，其中：

1. 大版本号更新表示一次里程碑开发的完成，包含了若干个 feature 的实现。
2. 小版本号更新表示一个 feature 的完成。
3. 补丁号更新表示发布的 feature 不变，只是修改 bug 。

     举例：

1. 某次发布是里程碑开发的结束，版本号为 1.0.0
2. 很快，上次发布的版本发现了 bug，紧急修复，再次发布，版本号为 1.0.1
3. 再次发现 bug，修复，重新发布，版本号为 1.0.2
4. 几个星期后，新增了几个功能，再次发布，版本号为 1.1.0
5. 几天后发现新增的功能有 bug，紧急修复，发布，版本号为 1.1.1
6. 再次新增功能发布，版本号为 1.2.0
7. 发现 bug，修复并发布，版本号为 1.2.1
8. 再次完成一次里程碑开发，发布，版本号为 2.0.0
9. ……以此类推

五 code review

     由于使用了git flow ，可以将code review机制很好的结合起来，当我们合并代码的时候，是需要MR（merge request）的，这时候需要向代码审核人提交你的合并请求。具体流程可参考GitLab Flow里的最后一部分。

 

六 使用git flow 开发流程简述

1.      从develop打feature分支，确定feature分支负责人（今后这个分支分出去的其它分支都由他负责，他负责MR时的代码评审）。
2.      在feature分支上开发，如其它同事的其它feature分支合并回了develop,会要求通过大家。如需要（一般是公共影响部分）在你自己的feature分支上合并develop上的代码。
3.      开发完feature分支代码，提交合并请求，合并至develop,由代码评审人评审通过后合并。合并完成后，删除feature分支。
4.      提测前，从develop中打出release分支给测试使用，如测试通过不需要修改，则合并回master和develop并删除；如有问题，可以在release分支上修改，修改完毕后，再合并回master,develop,并删除release分支。
5.      上线前，在maser分支上打出tag 
6.      线上有bug，从master打出hotfix分支修复，完成后，合并回 master和 develop ,删除hotfix分支。