CI/CD Git Flow

由于 git 代码管理比较混乱，所以记录一下 Git Flow + GitLab 的整体工作流程

一、Git Flow 简介

Git Flow 定义了一个围绕项目开发发布的严格 git 分支模型，用于管理多人协作的大型项目中实现高效的协作开发；Git Flow 分支模型最早起源于 Vincent Driessen 的 A successful Git branching model 文章；随着时间发展，Git Flow 大致分为三种:

  • Git Flow: 最原始的 Git Flow 分支模型
  • Github Flow: Git Flow 的简化版，专门配合持续发布
  • GitLab Flow: Git Flow 与 Github Flow 的结合版

关于三种 Git Flow 区别详情可参考 Git 工作流程

二、 Git Flow 流程

Github Flow 和 GitLab Flow 对于持续发布支持比较好，但是原始版本的 Git Flow 对于传统的按照版本发布更加友好一些，所以以下主要说明以下 Git Flow 的工作流程；Git Flow 主要分支模型如下

git flow

在整个分支模型中 存在两个长期分支: develop 和 master，其中 develop 分支为开发分支，master 为生产分支；master 代码始终保持随时可以部署到线上的状态；develop 分支用于合并最新提交的功能性代码；具体的分支定义如下

  • master: 生产代码，始终保持可以直接部署生产的状态
  • develop: 开发分支，每次合并最新功能代码到此分支
  • feature: 新功能分支，所有新开发的功能将采用 feature/xxxx 形式命名分支
  • hotfixes: 紧急修复补丁分支，当新功能部署到了线上出现了严重 bug 需要紧急修复时，则创建 hotfixes/xxxx 形式命名的分支
  • release: 稳定版分支，当完成大版本变动后，应该创建 release/xxxx 分支

在整个分支模型中，develop 分支为最上游分支，会不断有新的 feature 合并入 develop 分支，当功能开发达到完成所有版本需求时，则从 develop 分支创建 release 分支，release 后如没有发现其他问题，最终 release 会被合并到 master 分支以完成线上部署

三、Git Flow 工具

针对于 Git Flow，其手动操作 git 命令可能过于繁琐，所以后来有了 git-flow 工具；git-flow 是一个 git 扩展集，按 Vincent Driessen 的分支模型提供高层次的库操作；使用 git-flow 工具可以以更加简单的命令完成对 Vincent Driessen 分支模型的实践；
git-flow 安装以及使用具体请参考 git-flow 备忘清单，该文章详细描述了 git-flow 工具的使用方式

还有另一个工具是 git-extras，该工具没有 git-flow 那么简单化，不过其提供更加强大的命令支持

四、Git Commit Message

在整个 Git Flow 中，commit message 也是必不可少的一部分；一个良好且统一的 commit message 有助于代码审计以及 review 等；目前使用最广泛的写法是 Angular 社区规范，该规范大中 commit message 格式大致如下:

1
2
3
4
5
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

总体格式大致分为 3 部分，首行主要 3 个组成部分:

  • type: 本次提交类型
  • scope: 本次提交影响范围，一般标明影响版本号或者具体的范围如 $browser, $compile, $rootScope, ngHref, ngClick, ngView, etc...
  • subject: 本次提交简短说明

关于 type 提交类型，有如下几种值:

  • feat：新功能(feature)
  • fix：修补 bug
  • docs：文档(documentation)
  • style： 格式(不影响代码运行的变动)
  • refactor：重构(即不是新增功能，也不是修改 bug 的代码变动)
  • test：增加测试
  • chore：构建过程或辅助工具的变动

中间的 body 部分是对本次提交的详细描述信息，底部的 footer 部分一般分为两种情况:

  • 不兼容变动: 如果出现不兼容变动，则以 BREAKING CHANGE: 开头，后面跟上不兼容变动的具体描述和解决办法
  • 关闭 issue: 如果该 commit 针对某个 issue，并且可以将其关闭，则可以在其中指定关闭的 issue，如 Close #9527,#9528

不过 footer 部分也有特殊情况，如回滚某次提交，则以 revert: 开头，后面紧跟 commit 信息和具体描述；还有时某些 commit 只是解决了 某个 issue 的一部分问题，这是可以使用 refs ISSUE 的方式来引用该 issue

五、Git Commit Message 工具

针对 Git 的 commit message 目前已经有了成熟的生成工具，比较有名的为 commitizen-cli 工具，其采用 node.js 编写，执行 git cz 命令能够自动生成符合 Angular 社区规范的 commit message；不过由于其使用 node.js 编写，所以安装前需要安装 node.js，因此可能不适合其他非 node.js 的项目使用；这里推荐一个基于 shell 编写的 Git-toolkit，安装此工具后执行 git ci 命令进行提交将会产生交互式生成 Angular git commit message 格式的提交说明，截图如下:

git ci

六、GitLab 整合

以上 Git Flow 所有操作介绍的都是在本地操作，而正常我们在工作中都是基于 GitLab 搭建私有 Git 仓库来进行协同开发的，以下简述以下 Git Flow 配合 GitLab 的流程

6.1、开发 features

当开发一个新功能时流程如下:

  • 本地 git flow feature start xxxx 开启一个 feature 新分支
  • git flow feature publish xxxx 将此分支推送到远端以便他人获取
  • 完成开发后 GitLab 上向 develop 分支发起合并请求
  • CI sonar 等质量检测工具扫描，其他用户 review 代码
  • 确认无误后 master 权限用户合并其到 develop 分支
  • 部署到测试环境以便测试组测试
  • 如果测试不通过，则继续基于此分支开发，直到该功能开发完成

6.2、创建 release

当一定量的 feature 开发完成并合并到 develop 后，如所有 feature 都测试通过并满足版本需求，则可以创建 release 版本分支；release 分支流程如下

  • 本地 git flow release start xxxx 开启 release 分支
  • git flow release publish xxxx 将其推送到远端以便他人获取
  • 继续进行完整性测试，出现问题继续修复，直到 release 完全稳定
  • 从 release 分支向 master、develop 分支分别发起合并请求
  • master 合并后创建对应的 release 标签，并部署生产环境
  • develop 合并 release 的后期修改

6.3、紧急修复

当 master 某个 tag 部署到生产环境后，也可能出现不符合预期的问题出现；此时应该基于 master 创建 hotfix 分支进行修复，流程如下

  • 本地 git flow hotfix start xxxx 创建紧急修复分支
  • 修改代码后将其推送到远端，并像 master、develop 分支发起合并
  • develop 合并紧急修复补丁，如果必要最好再做一下测试
  • master 合并紧急修复补丁，创建紧急修复 tag，并部署生产环境
CI/CD
#CI/CD #Git
CI/CD Git Flow
https://mritd.com/2017/09/05/git-flow-note/
作者
Kovacs
发布于
2017年9月5日
许可协议