我记得本科时写论文，当时不会版本管理工具，每天都是按时间后缀备份个新文件夹；某同学提醒我用 Git，我还不屑一顾——无知又自负。最近，我和一些非软件相关行业的朋友聊天，他们竟然也是用 Git 做版本控制的，还用得很溜。想来，高效的生产工具在任何行业都是共通的。今天就借机聊聊我们在生产中常用到的几种 Git 工作流程。
入门版
入门版 Git 模型只有一个默认的 master 分支，操作基本无外乎 pull 和 push。
这种工作流很简单，我自己写博客就是一个入门版 master 分支：每天写一点，顺道加个 commit 标记一下，基本就没啥他用了。学生时代，我还见过某对小情侣 PK A 题，他们也是这种 Git 模式，回想起来还是挺有趣的。不过工程生产中，应该不会有团队使用这种工作流；缺点显而易见：冲突和回滚的代价太大了。
普通版
组成开发团队后，我们得确保不会直接操作主分支了。最朴素的工作流就是：
- 开发新功能前，每个人从 master 分支切出一条专属的 feature 分支
- 功能实现后，将 feature 分支合并到 master 分支
- 假如出现冲突，在自己的分支里解决冲突，再尝试合并
这种工作流算是正式开启了团队成员的“并发”工作。每个人只需关注自己的分支，即便有冲突也是在自己熟悉的分支代码上修改。
主分支功能单一，只需注意 MR（Merge Request），这使得集成一些自动化操作变得简单可行了。新功能合并到 master 分支，会立即触发生产环境的部署；这确实挺方便的，但是副作用也很明显：生产环境变得不稳定——新功能只在本地开发环境证明可行，线上就不见得了。那该如何改进呢？
专业版
我们需要一个中间态，一个既能快速合并新功能，又能证明线上运行可行的分支——develop 分支。
develop 反映的是最新的代码实现效果：
- develop 是从上一迭代的 master 切出的分支
- feature 则由 develop 分支切分出来；新功能实现后，第一时间就合并到 develop 上
- 遇到 bug 也是先修复 develop 代码
- 通常 develop 分支也能触发自动化部署——staging 环境——帮助开发或测试人员第一时间看到线上部署的效果
master 则是相对稳定的分支：
- master 分支只由充分测试后的 develop 分支合并而来
- master 代码可以直接部署到生成环境，或是交由 shipment 团队发布到商业环境中
- master 分支每次更新后，通常会打个 tag，用于标记版本号
我自己所属的团队曾长期使用这种 Git 工作流。在一个开发迭代里，如果有很明确的开发阶段和测试阶段，这种工作流还是很实用的。只不过，有时候测试方速度较慢，甚至能拖到下一个迭代中，这时的 develop 分支就比较尴尬了——既要处理新周期 feature，又要修复上一迭代的 bug，显然力不从心了。
旗舰版
如何解决上述烦恼？再加一个中间态呗——release 分支。
Release 分支
当某一迭代的新功能开发完毕后，我们会从 develop 分支切出一个 release 分支：
- Release 分支一般用作 bugfix，绝大多数的人工测试——包括 Scenario 测试、回归测试、UI 测试等等——都会基于这个分支的代码进行；此外，Release 也可能合并一些文档，或是非功能相关的业务代码，但是切记加入与该发布版本不相关的信息。
- 而 develop 分支基本只服务于开发人员；release 测试阶段，develop 也可以同步进行下一迭代的功能开发。
Release 代码被充分测试后，就可以合并到 master 分支，并打上版本 tag；与此同时，Release 也需要立马合并回 develop 分支，使 develop 分支保持最新代码。
Hotfix 分支
这里还存在一个问题，假如 master 分支的代码又发现了新的 bug，该如何处理？
Master 指向的是生产环境，修复生产环境的 bug 就是所谓的打补丁（patch）了。我们通常会从 master 的特定 tag 上切出一个叫 hotfix 的分支；bug 修复后，再合并回 master。使用 hotfix 分支的好处就是“快”——迅速修复、迅速发布，避开了 develop -> release -> master 的冗长步骤。
打完补丁后，我们也应尽快将 hotfix 代码 cherry-pick 到最近的 release 分支或是 develop 分支，使分支保持最新代码。
这种 Git 工作流最早是在十年前，由一个叫Vincent Driessen的作者发布于自己的博客上，之后被迅速借鉴到各大公司的软件工程上。后来，他还自己开发了一个 git 扩展工具——gitflow，指导开发人员使用这套开发流程管理代码。
但是遇到更复杂的业务场景，我们又该怎么继续扩展 git 工作流呢？很简单，无限地添加不同命名的分支。
没有一个问题是一个中间态不能解决的，如果有就再加一个中间态！
我就听说过类似的事，某厂要长期同时开发三个迭代周期的分支。要知道每个迭代光开发就是数个月；每个分支又会处在不同阶段的测试周期中，什么时候结束还不知道；每个分支各自的依赖本身还在升级；还会接受客户的要求，在不同版本的分支里添加新需求。大家可以思考一下该怎么管理分支。
小结
OK，这期介绍了四种开发中常用到的 git 工作流，建议大家按照实际需求选取一种模式。也没必要一上来就搞“旗舰版”，上述四种模式我都体验过，也是随着项目变更逐步升级到进阶版的。很多时候，我们的工程并没有那么复杂，完全可以在其他方面动脑经解决问题，而不是无限地增加分支。Git 只是一款工具，不是解决问题的关键，人才是！
