Gitflow Workflow

什么是 Gitflow 工作流?

Gitflow Workflow插图

Gitflow工作流是以Git作为源代码管理工具的团队的一种管理,开发,维护,发布的工作流程,它为项目的发布维护等工作定义了严谨的分支管理模型,同时也为大型项目提供了健壮的管理框架。
Gitflow工作流并不会创造新的Git概念和命令,相反,Gitflow工作流为每个指定的分支定义严格的功能角色,定义每个分支负责明确的工作任务,指定其在适当的时候进行适当的反应。另外,Gitflow工作流将会使用独立分支负责维护,开发,发布等工作。当然我们仍然需要使用如pull requests等工作方式来进行团队协作。

Gitflow工作流是怎么工作的

Gitflow工作流仍然使用中心仓库作为开发团队信息交流中心,和其他的Git工作流程一样,开发人员使用本地仓库进行工作,然后推送提交工作到中心仓库,唯一的区别就是Gitflow工作流的分支组织结构不一样。

Main Branch

仓库启动时,需要指定一个主分支 master,分支如下:

Gitflow Workflow插图1

主分支将一直存在于这个仓库,直到项目结束或者仓库删除。

Develop Branch

和使用单一的master分支不一样的是,Gitflow工作流将使用两个分支(master分支和dev分支)来记录整个项目的履历。master分支用于记录项目的官方发布履历,而dev分支作为功能(feature)分支聚集中心,同时也约定master分支将使用版本号来进行标记,以备后续的查询和引用,这两个分支的关系如下:

Gitflow Workflow插图2

Gitflow工作流的后续工作都将围绕这两个分支展开。
而且这两个分支将不会删除,一直存在

Feature Bugfix Branches

严格意义上讲,每一个新的开发工作内容都应该在独立的分支中完成,这些工作在完成后都应该被推送提交到中心仓库以备持久,备份以及相互协作。但是需要注意的是,feature/bugfix分支不能从master分支继承,应当从dev分支继承,当一个开发工作结束后,这些完成的工作都应该推送提交到dev分支,切记,feature/bugfix分支不能直接和master分支进行交互,到这一步,代码分支结构如下:

Gitflow Workflow插图3

注意:此处的 feature/bugfix 分支都是从 dev 分支开启的,并且只能合并到 dev

bugfix 分支不止可以在 dev 开发时使用,也可以在 release 即将发布时使用。主要用于场景是,功能开发中,前一个功能出现问题,这时可以启动一个 bugfix 来进行修改;同样的在 release 即将发布之前,如果测试出来问题,也可以启动一个 bugfix 来进行修改。

注意:bugfix 严格情况下,只能在 dev 和 release 分支上启动

Release Branches

当我们要进行正式发布的时候,我们需要创建独立的release分支,加入release分支后代码分支结构如下:

Gitflow Workflow插图4

当develop分支包含了足够适合发布的功能或者达到了发布计划日期后,将会启动发布流程,我们前面也提到Gitflow工作流的每项工作都基于独立的分支进行,因此我们将从dev分支衍生(fork)出独立的release分支,从创建新的release分支开始,我们就进入了新的发布周期,因此这个release分支将不再接受新的功能的加入,但是严重bug修改除外,后续的文档更新,以及其他任何和这次发布相关的工作都应该在这个release分支上进行,一旦发布工作准备完成,并确定要上市的时候,这个release分支需要合并回master分支,并且使用版本号为master分支进行标记,同时由于release分支可能存在bug的修改等相关改动,因此这些修改也需要合并到dev分支,以备这些修改能正确反映到后续版本的发布中。

使用独立的发布分支可以让发布人员进行发布的同时,也不影响开发人员进行后续版本的开发,这样也就让开发各个周期定义变得更清晰,当然,我们对release分支有些约定

  1. release分支必须从dev分支继承
  2. release分支在完成发布工作后需要合并到master分支,同时按需要合并回dev分支
  3. release分支命名约定为:release/{version}
  4. release合并完成后可根据自己需求选择保留或者删除

Hotfix Branches

hotfix(maintenance)分支用于快速修正线上产品出现的严重问题,hotfix分支是唯一直接从master分支衍生(fork)的分支,当hotfix的工作完成后,这些工作应该合并回master分支和dev分支,如果当前有发布工作正在执行,这些工作同时需要合并到当前的release分支,同时master分支需要使用更新版本号进行标记,代码分支结构如下:

Gitflow Workflow插图5

使用独立的hotfix分支,可以让开发团队可以快速的定位紧急的问题,但同时也不会打断当前开发工作的流程,也不需要再等到下班版本的更新。
实际上可以把hotfix分支看做一个直接和master分支进行交互的临时release分支。

总结

以上就是一个项目的完整的开发git工作流,主要针对于开发人员的代码开发和发布。

文章来源于互联网:Gitflow Workflow

THE END
分享
二维码