GitFlow在实际中使用的摸索

约定不等于承诺〃 2022-03-10 16:20 232阅读 1赞

# 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分支，其他分支因为是临时分支，都删除了。

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

答：

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