导言
现在开发过程中使用的版本管理工具多数都是Git，Git很强大的一个功能是分支管理，那么在开发过程中，对于分支管理有没有什么规范呢？答案当然是肯定的，那就是Git工作流。
分支管理
Android 组的分支管理使用标准的 GitFlow 工作流，建议使用Git客户端SourceTree，支持Git工作流。
分支描述
在 GitFlow 工作流中一共有5种分支：
develop
常驻分支，功能分支和提测分支都从此分支拉取。
master
常驻分支，用于归档已上线代码，热修复分支从此分支拉取。每个版本上线后需在此分支打一个 tag 来标记版本。 tag 名为 "v + 版本号"，如 v2.0.0
feature
功能开发和提测分支，用完即删。
当需要开发新功能时，直接使用 git-flow 工具的 start feature 功能拉取新分支。 分支名为 feature/+功能名或版本号，如 feature/login 或 feature/2.0.0
开发时，每个成员以子功能点在 feature 分支上拉取新分支用于开发。单个子功能点开发完后如需单独提测，直接在当前分支上提测。测完后提 MR 合并至主 feature 分支。
功能全部开发完后，使用 git-flow 工具的 finish feature 功能结束掉此分支。git-flow会自动将其合并至 develop 分支。
release
大版本提测分支，用完即删。
一个迭代做完后，用 git-flow 工具的 start release 功能拉取新分支用于测试。分支名为 release/+版本号，如 release/2.0.0
每个成员在此分支上拉取各自分支用于修复 bug。 bug 修复完后用 git-flow 工具的 finish release 功能结束掉此分支。git-flow会自动将其合并至 develop 和 master 分支。
hotfixes
热修复分支，用于紧急修复线上 bug。 用完即删。使用 git-flow 的 start hotfix 和 finish hotfix 操作。结束后git-flow会自动将其合并至 develop 和 master 分支
禁止直接往分支合并代码。所有人需通过 gitlab 的 Merge Request 功能合并代码，方便 code review。
分支工作流
GitFlow 完整工作流程如下图:
打包测试流程
青石证券 App 目前一共有三个 buildType:
debug
开发内部用的 buildType，不对测试可见。包名为包名加.test后缀， 应用名为青石证券开发版，未混淆代码。
preview
测试用的 buildType。包名为包名加.test后缀， 应用名为青石证券测试版，已混淆代码。此 buildType 只能打测试环境或预发布环境的包。
release
上线用的 buildType。包名没有后缀， 应用名为青石证券版，已混淆代码。此 buildType 强制打生产环境的包。
提测时，开发打测试环境或预发布环境的 preview 包给测试测。测到没有 bug 之后，开发打生产环境的 release 包给测试测生产环境。测试通过后直接拿最后测试的 release 包上线。
大致开发流程如下:
总结
熟练使用这套Git工作流之后，可以大幅提高开发效率，规范开发流程。
写于2018.05.23下午18:00（位置：深圳南山）
