Git工作流Workflow

---

Git工作流物语.jpg

导言

现在开发过程中使用的版本管理工具多数都是Git，Git很强大的一个功能是分支管理，那么在开发过程中，对于分支管理有没有什么规范呢？答案当然是肯定的，那就是Git工作流。

分支管理

Android 组的分支管理使用标准的 GitFlow 工作流，建议使用Git客户端SourceTree，支持Git工作流。

分支描述

在 GitFlow 工作流中一共有5种分支：

1. develop

常驻分支，功能分支和提测分支都从此分支拉取。

2. master

常驻分支，用于归档已上线代码，热修复分支从此分支拉取。每个版本上线后需在此分支打一个 tag 来标记版本。 tag 名为 "v + 版本号"，如 v2.0.0

3. feature

功能开发和提测分支，用完即删。

当需要开发新功能时，直接使用 git-flow 工具的 start feature 功能拉取新分支。 分支名为 feature/+功能名或版本号，如 feature/login 或 feature/2.0.0

开发时，每个成员以子功能点在 feature 分支上拉取新分支用于开发。单个子功能点开发完后如需单独提测，直接在当前分支上提测。测完后提 MR 合并至主 feature 分支。

功能全部开发完后，使用 git-flow 工具的 finish feature 功能结束掉此分支。git-flow会自动将其合并至 develop 分支。

4. release

大版本提测分支，用完即删。

一个迭代做完后，用 git-flow 工具的 start release 功能拉取新分支用于测试。分支名为 release/+版本号，如 release/2.0.0

每个成员在此分支上拉取各自分支用于修复 bug。 bug 修复完后用 git-flow 工具的 finish release 功能结束掉此分支。git-flow会自动将其合并至 develop 和 master 分支。

5. hotfixes

热修复分支，用于紧急修复线上 bug。 用完即删。使用 git-flow 的 start hotfix 和 finish hotfix 操作。结束后git-flow会自动将其合并至 develop 和 master 分支

禁止直接往分支合并代码。所有人需通过 gitlab 的 Merge Request 功能合并代码，方便 code review。

分支工作流

GitFlow 完整工作流程如下图:

image

打包测试流程

青石证券 App 目前一共有三个 buildType:

• debug

开发内部用的 buildType，不对测试可见。包名为包名加.test后缀， 应用名为青石证券开发版，未混淆代码。

• preview

测试用的 buildType。包名为包名加.test后缀， 应用名为青石证券测试版，已混淆代码。此 buildType 只能打测试环境或预发布环境的包。

• release

上线用的 buildType。包名没有后缀， 应用名为青石证券版，已混淆代码。此 buildType 强制打生产环境的包。

提测时，开发打测试环境或预发布环境的 preview 包给测试测。测到没有 bug 之后，开发打生产环境的 release 包给测试测生产环境。测试通过后直接拿最后测试的 release 包上线。

大致开发流程如下:

image.png

总结

熟练使用这套Git工作流之后，可以大幅提高开发效率，规范开发流程。

写于2018.05.23下午18:00（位置：深圳南山）