工作中我是怎么使用git的--git教程 下
本篇为下篇,介绍git flow
下篇
Git Flow
在使用git时,团队中需要制定统一的工作流程,也就是git flow
,避免在开发过程中出现混乱的git版本。混乱的git版本会对开发带来很多不必要的麻烦,诸如代码丢失,生产环境错误。
目前主流的git flow
模型是由 Vincent Driessen提出的,适合于按需求有计划性的进行项目发布,同时定义了master, release, develop, feature, hotfix
这几种分支类型,赋予了他们相应的职责概念。各位可以翻阅原文和相关译文进行了解,本篇教程在此模型基础上做了一些删减和修改,仅保留了以下分支类型,并修改了一些概念。
分支类型和概念
master
,用于发布生产环境的分支,该分支上的代码必须是测试通过的代码,只接受来自于feature
和hotfix
的分支合并每次发布需要进行tag标记以便于出错时进行回滚。develop
,测试分支,所有feature
分支开发完毕的功能需要合并到develop进行测试后才能合并到master
。develop
可能会存在多个。develop
不能合并到master
。feature
,开发分支。hotfix
,紧急修复分支,在master
分支出现BUG需要进行紧急修复时使用。
流程规范
先来看下图,这里展示了在当前4种分支类型下我们进行的工作流。
master和develop
在之前我们简单介绍过,master
是用于发布的分支,因此需要与生产环境保持绝对一致,不能出现直接提交的情况。在每次master
发布上线时,我们需要继续tag
标记,万一生产环境出现紧急问题可以迅速通过tag
进行版本回滚。
develop
是用于测试的分支,可能在一个develop
分支种存在多个来自于feature
的开发功能,因此不能直接从develop
合并到master
上,避免出现将未测试通过的功能偷跑上线的情况发生。一般一个develop
分支对应一个测试环境,根据团队进行可以部署多个测试环境和多个develop
分支。
master
和develop
分支通常不允许出现直接在进行commit
和push
操作,也就是直接这些分支上提交代码,这些分支只能通过merge
进行修改。这些限定在大部分git平台上均有实现,通过设定为保护分支可以防止被删除,通过权限设置可以只允许部分人员进行push
操作。
feature
这个分支是开发者最常用到的分支之一,在接到新的功能需求时,feature
需要从当前最新的master
切出分支来进行开发。多个feature
之间是互相独立的,因此也会存在代码冲突的情况,这就需要各位开发人员互相的协调合作了。这里说明以下feature
的操作流程。
- 有新需求,从最新的
master
上切出分支,进行功能开发。 - 在
feature
上开发完毕功能后,需要先merge
到develop
分支进行测试。在合并之前,需要将最新的master
合并到当前分支来,确保不会有生产环境的功能遗漏而导致测试不通过的情况。 - 测试人员在
develop
上出现问题,由开发人员在feature
上进行修复后,重新操作步骤2发布到测试。 - 测试通过,
merge
到master
进行上线。 - 上线完毕,删除
feature
分支。
这便是feature
的整个生命周期,这里有人可能有疑惑,如果上线后出现BUG要怎么办呢?别着急,马上我们就来讲讲hotfix
。
hotfix
一旦feature
发布到生产环境后出现BUG需要紧急修复,但是feature
的职责其实在merge
到master
时就已经终结了,现在我们需要的一个补救分支hotfix
。
hotfix
就如同名字一样,用于生产环境的快速修复,一旦生产环境出现问题。
- 首先我们要将版本进行回滚。
- 然后立刻切出
hotfix
,进行问题排查和修复。 - 在修复完毕后同样需要进入到
develop
进行测试,千万不要盲目的自信上线。 - 在测试通过之后,
merge
到master
进行上线。 - 上线完毕,删除
hotfix
分支。
不过要是这次上线完了还有问题,那就再来一个hotfix
!
总结
本次给大家介绍了一下git flow
的基本概念和情况,这里需要强调的是,git flow
是一种规范,本期的git flow
只是基于我个人对工作流的理解和应用,希望能对你有所帮助和启发。
不同的团队会存在不同的情况,并且团队慢慢发展,不存在说有一个固定且一成不变,并能够完美适用当下情况的git flow
规范。一旦当前的git flow
规范开始成为团队开发的绊脚石,就要考虑进行相应的改良。