鱼池工作流——git pond flow

相信各位对一下git的工作流多多少少会有所了解

• Git flow
• Github flow
• Gitlab flow

不清楚可以看这

先说说在使用gitflow过程中的几个痛点：

1. 等待——每当有多人开发时便需要注意测试、预上线等分支是否别人暂用，被暂用则需要等待别人使用完之后测试；
2. 冲突后置——没次上线如临大敌，到最后mr那一刻才知道有多少冲突，一波操作猛如虎，说不定还有bug。大范围代码的合并，对于管理者也是一个大挑战。review所有代码需要耗费大量时间和精力；
3. 无法回退——如果发现其中某个功能因特殊原因无法上线，这个时候回退版本需要大刀阔斧，很多冲突说不定还得重来。蓦然回首，又是一个通宵；
4. 部署——因为分支的不固定，每次需要部署到dev或者其他环境都需要手动去操作，积少成多浪费的不是一丁半点时间。

为了解决以上痛点，特地设置了一套git工作流。

先瞅瞅这个工作流的流程图

主要实现

1. 优点

• 各个功能独立，既上既用
• 单独功能上线，review代码更友好
• 0等待，实现理论上的无限环境
• 冲突前置，在上第一个固定分支时就会将冲突暴露

2. 缺点

• 冲突解决不够干净利落，需要注意解决冲突后的功能上线的先后顺序

说明

1. 环境说明：

• 仓库使用的是gitlab；注意修改mr配置，如下

• 使用Jenkins进行部署

2. 分支说明

• master：线上分支（受保护分支）
• staging：预上线分支（受保护分支）
• test：测试分支（受保护分支）
• dev：开发测试分支，开发人员可将功能分支merge到该分支push到远端，但不能在dev上做任何修改
• 功能1、2、3…：开发分支（基于master拉出来，上线之后删除）

开发流程

1. 基于master，拉出分支staging、test、dev…(与Jenkins环境一一对应)。分支的设置如下

注意：dev分支不需要设置为受保护分支，此分支开放给开发人员原因如下：

• 检验功能分支是否与dev分支中其他功能冲突
• 将本地功能分支merge到dev分支，push到远端；此处可配合Jenkins实现自动部署，配置在此。如果贵司做了平滑部署，其他固定分支可以设置合并mr时触发自动部署 （这里可以妥妥的解决痛点4）

2. 基于master拉出各个功能分支，如：fea1、feat2、feat3…
3. feat分支完成功能开发，推送到远程 => 将远程dev拉取到本地 => 本地feat分支merge(禁止rebase)到本地dev分支，这时会有一下两种情况（这里完美解决了痛点2，冲突在自测阶段就解决了）:

• 有冲突 => 记录好冲突，回退dev到为merge前的状态 => 切换回feat分支，解决冲突请看下方冲突解决姿势
• 没有冲突 => push本地dev（每个固定分支都有相应阶段的独立功能，完成一个固定分支就是无数个虚拟测试环境，搞定痛点1）

4. dev环境自测通过后 => 远程feat提mr到test => 测试测试通过后 => 远程feat提mr到staging => 预发布环境通过后 => 远程feat提mr(勾选删除分支)到master（如此每个feat都可独立上master实现了单独功能上线）
5. 若出现其中某个功能上了master，又临时无法上线时，便可将master回退到该feat合并前的状态，然后将后面需要的功能重新合进去便可（解决无法回退的痛点）。

注意事项

1. git账号配置

由于会同一个人提交的git，commit记录里出现了两个用户记录，所以建议将工作的gitlab的账号配置到全局。

git config --golbal user.name "XXX"
git config --golbal user.email "xxx@aa.com"
复制代码

如果有特别的项目或者第三方库可以在相应项目目录设置local账号

git config --local user.name "XXX"
git config --local user.email "xxx@aa.com"
复制代码

2. 禁止本地修改dev分支代码

本地修改dev的代码会出现的情况

• 代码不在feat分支上，当feat分支合并到其他如test分支时，发生代码丢失
• 代码在dev上，同时又修改了feat，便会产生代码冲突

建议按链接的方式配置一下终端：www.cnblogs.com/weixuqin/p/…
可清楚知道当前所在的分支。

3. 禁止将dev、test、staging等其他分支合并到开发分支（master）

将固定分支合到本地开发分支，有可能将他人正在开发的功能合到自己分支。此时若将合过来冲突解决之后合到每个固定分支都将会有冲突。（master用来新建开发分支）

4. 不要使用base

由于rebase合并到另外分支如：dev，会生成新的commit id，如B；如果feat修改了B(commit id)相同的位置，再次合并到dev便产生冲突。

冲突解决姿势

1. 在不同行修改

固定分支回退merge=>切换回本地分支修改

再次合并到固定分支，冲突解决（dog）

2. 沟通修改

固定分支回退merge=>协商test1集中改=>基于test2冲突文件回退到master=> test2新建分支命名得知道以后要在test1后面上线

合并到固定分支