GitFlow在实际中使用的摸索

网上介绍Git Flow的博客非常多，本文参考了网上的资料，结合自己以往使用Git中的一些心得体会和思考，重新总结和归纳，最重要的是附带一个带有场景的实际的例子，去演示Git Flow在实际的开发中，要如何用。当然受限于作者的知识和能力，也会有考虑不周，或待改进的地方。

建议

我们的开发流程，一定要有版本的概念，每次发布，都要有版本号，即使是bug修复，也要有版本号。每个版本号，更新了什么功能，修复了什么bug，都是要记录清楚的，这样管理就会变得可控和简易。切记不要小作坊的思维模式，“随意上线”，”随时上线”的状态，这样会导致相关人员疲于奔命应付，导致流程相当难管理。上线了，即使线上有bug，只要不是严重的，都应该忽视，等在下一个版本里进行修复。这样开发人员、测试人员、产品人员等等才会有更多的精力投入到下一个版本的工作中。

一定要认识到，发布是一个流程，有前期的需求调研、原型的设计、UI的设计、编码、测试、环境准备和部署等等流程组成。切记不可低估和省略测试环节，草草测试，草草上线，只会让整个流程陷入泥潭，使各方人员陷入疲于应付的状态，从而变成恶性循环。

概述

Git Flow中master和develop分支是长期存在的，它们是主要的分支。release、hotfix、feature是临时分支，是辅助性的分支，在某个时候会删掉。

注意：develop分支有时简写为dev，hotfix有时也会用bugfix或fixbug，反正不管怎么叫，其作用是固定的。

详细解释各分支

master

用于记录上线的历史版本。每次上线后，都会将所上线的代码记录在此分支，并打上版本tag。（长期分支）
develop

用来记录开发（编码）的主线，用来合并各个开发人员协作开发的各种功能特性（feature）。（长期分支）
hotfix

临时从master中拉出来的分支，用于紧急解决线上的bug，上线修复后必须合并到master和develop，并且删除该分支。（短期分支，用完就删）
release

上线用的就是该分支，待开发组长把各feature分支合并到develop后，由develop拉出release分支，供QA部署测试线并进行测试。上线后将release合并到master并在master打上版本号tag，然后删除该分支。（短期分支）
feature

用于开发某个特性（功能）的分支。

详细流程，详细例子

假设有A、B、C三个开发，A是组长。目前线上的版本是v1.0.0，现在要开发v2.0.0版本。目前git仓库中有master分支和develop分支，其他分支因为是临时分支，都删除了。

A、B、C分别从develop分支拉出feature分支，在各自的分支上进行开发，具体feature分支名：feature_v2.0.0_a、feature_v2.0.0_b、feature_v2.0.0_c （*注意）
最后开发好后，只有组长A有权限将feature_xxx分支合并到develop里。合并好后通知QA可测。
QA从develop拉出release分支，QA基于release分支进行测试（注意：这里只有QA才有权限从develop拉出release分支，避免在QA测试期间开发人员可以随意往release分支推代码）
QA发现有bug，假如由C进行修复，由C在feature_v2.0.0_c进行修复，然后再由组长A再次合并到develop里并通知QA已经修复
QA将develop分支合并到release里，并验证bug是否修复。如果未修复或还有bug，重复流程1. 直至认为测试完成。QA通知运维发布。
运维用release分支的代码里打包发布。
发布完成。
运维将release分支的代码合并到master，并打上v2.0.0标签，删除release分支。
发现线上bug，项目负责人评估是小bug，暂不修复！！！（小bug不影响的不要处理，待下个版本处理，否则会被拖入泥潭）
调研v3.0.0功能，讨论需求，原型设计，UI设计，准备开始编码工作
A、B、C，从develop拉出feature_v3.0.0_a、feature_v3.0.0_b、feature_v3.0.0_c分支，删除feature_v2.0.0_a、feature_v2.0.0_b、feature_v2.0.0_c分支。（**注意）
A、B、C三人赶进度开发v3.0.0需求
发现线上bug（此时线上版本是v2.0.0），项目负责人评估是大bug，得紧急修复
运维从master分支的v2.0.0的tag里拉出hotfix分支
A、B、C三人从hotfix拉出hotfix_a、hotfix_b、hotfix_c
待bug修复后，A组长负责把hotfix_a、hotfix_b、hotfix_c合并到hotfix，并通知QA进行验证
QA在hotfix的基础上打包部署测试环境并进行测试，测试有问题则重复流程，直至认为测试完成。QA通知运维发布。
运维用hotfix的代码打包发布
发布完成，bug已修复
运维将hotfix分支的代码合并到master，并打上v2.0.1的tag，合并hotfix到develop以便下次上线包含了缺陷修复（也可通知A去合并），运维删除hotfix
A、B、C继续开发v3.0.0的功能

注意：

关于feature系列的分支的命名，其实相对来说比较宽松，约束规则较少，例如：假如ad广告模块功能需要由2个人来完成，可以feature_v2.0.0_ad_a、feature_v2.0.0_ad_b，而c去做活动模块，可以用feature_v2.0.0_activity_c也可以更随意feature_v2.0.0_c。甚至，直接不用指定v2.0.0了，因为v1.0.0在上线后就删掉了，直接用feature_a、feature_b、feature_c也行。

什么时机删除旧的、已经上线了的feature分支（如feature_v2.0.0_a、feature_v2.0.0_b、feature_v2.0.0_c），这个其实没有严格的要求，其实可以在上线后就删除。

关于数据库版本的思考

这样子做好不好

上线了v2.0.0将开发库复制一份v3.0.0的，用于开发新版本。例如rms-back_dev_v2备份出rms-back_dev_v3，v3版用于开发新功能，当线上有bug的时候可以连回v2进行调试。

个人观点

如果是小系统小库，备份并不麻烦且很快速。这么做还是比较好的，因为保留了一份跟线上数据库一致的数据库。

反对的声音：

有人可能会说，不备份rms-back_dev_v2也行呀，假设线上有bug，从QA测试的库rms-back_test中复制一份用于改bug即可。

答：

开发库可能存在配置数据，跟测试库的不一样，既然备份如此容易，何不备份上线新版后备份开发库? 2、小团队甚至没有测试库，直接由研发进行测试后上线。
如果是大的系统，备份并不现实，尤其是库多、数据多的情况下。这时候该怎么办? 开发库库表被改成了新版，但线上又有bug。这时候由具体某个负责的开发自行去想办法，例如可以想办法还原（从测试库还原等），况且对于大型公司，每个人负责一小块，难道作为开发还记不住自己改了哪些库表?难道还还原不回去?况且对于稳定的系统，频繁、不兼容式的改库表不会是常态。

文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/135338.html