Git flow在实践中的改进

原文地址: juejin.im/post/5d83ad…

在团队协做开发中, 各成员须要互相配合来完成功能的开发, 测试和发布. 但各成员习惯各异, 每一个人对如何协做的理解也不一样, 所以须要一个协做模型来规范团队不一样职能的人员以及相同职能的人员如何配合.

下面将基于Git来进行工做流层面的分析.

传统的Git flow

比较传统的一个Git flow是来自Vincent Driessen的分享, 总体交互图以下:

A successful Git branching model.

在这个模型中, 有两个主分支和其它功能分支, 主分支包括:

• master: 存放着生产级别的代码.
• development: 存放着最新开发的,可集成的功能的代码.

其余功能分支包括:

• Feature branches: 基于development建立的分支, 用于新功能的开发.
• Release branches: 基于development建立的分支, 用于发布新的功能, 稳定运行一段时间后合并到master分支, 做为最终的发布.
• Hotfix branches: 基于master建立的分支, 用于修复bug.

适用场景分析

这个模型适用的场景有:

• 各阶段开发的功能明确: 由于发布是直接从development中建立新的release分支, 若development中有未完成(开发或测试)的功能则会影响版本的发布.
• 大量而低频的发布: 由于development中可能含有多个功能, 所以须要各功能都测试完毕后才能发布. 如桌面应用, 移动应用的开发等.

不适用的场景:

• 少许和高频的发布.
• 多环境部署(如开发,测试和生产). 如Restful API的开发等.

改进的Git flow

针对传统Git flow的问题, 改进完后模型以下图:

该模型包含三个主分支和其余功能分支, 主分支包括:

• development: 用于新功能的开发端测试(做为开发者本身测试)和集成(如先后端的API集成).
• staging: 测试分支, 已完成开发端测试和集成的功能分支会合并到这里, 待测试人员测试.
• production: 生产分支, 存放生产级别代码; 功能分支经过测试人员在staging环境中的测试后, 将合并到该分支.

development和staging分支的初始化都基于production分支.

其余功能分支包括:

• Feature branches: 基于production建立的分支, 用于新功能的开发; 命名格式为feature/feature-name, 如feature/payment;
• Bugfix branches: 基于production建立的分支, 用户普通bug的修复, 合并流程同feature分支;命名格式为bugfix/bug-name.
• Hotfix branches: 用于紧急bug的修复, 可直接合并至production分支, 再分别合并到development和staging分支, 命名格式为hotfix/bug-name.

全部的功能分支都只在开发者本地, 不能上传到远程仓库.

该模型的运行流程以下:

1. 获得一个功能需求如支付, 基于production分支建立一个新的功能分支feature/payment;
2. 切换到功能分支feature/payment进行开发;
3. 本地开发结束, 将feature/payment分支合并到development分支, 进行开发端测试和集成;
4. 若在开发端测试和集成中发现问题, 切换回feature/payment分支去修复问题, 修复完后执行步骤3;
5. 若在开发端测试和集成中没有问题, 将feature/payment分支合并到staging分支, 让测试人员来测试;
6. 若测试人员在staging中发现有关该功能的问题, 切换回feature/payment分支, 修复完后执行步骤3;
7. 若测试人员在staging中认为该功能已测试完毕, 则将feature/payment分支合并到production分支.

规则

为了保证该模型的顺畅执行, 团队成员还应遵照如下几条规则:

1. 全部的功能分支都须要基于最新的production分支建立;
2. 全部的功能分支都只在存在开发者本地, 不能上传到远程仓库, 远程仓库只有主分支;
3. 主分支(development, staging和production)之间不能相互合并;
4. 主分支只能合并功能分支(如feature,bugfix和hotfix分支);
5. 功能分支最终要合并到全部的主分支中.
6. 每次合并都要留有记录(merge命令带--no-ff);

经过以上改进以后, 该模型就能够支持多环境部署, 而且保证功能合并的独立性.

固然, 不一样团队的业务场景也有差别, 对各类模型也须要有相应的调整;

总而言之, 没有绝对完美的模型, 场景决定了适用的模型.

参考

• A successful Git branching model.