客户端Git版本管理流程分享

发表于 | 分类于

客户端Git版本管理流程分享

1
2
3
4
5
依托Git自身强大的Gitflow特性，我们可以更高效地进行团队内多人或者跨业务线之间的开发协作，   
在需求版本开发中，可以进行对团队内每个成员的代码质量管控，互不干扰相互独立的需求开发，避免      
多人代码糅合发生冲突或冗余需求下架污染发布版本带来的各种风险  
Git分支管理分为常驻分支和临时分支

常驻分支

master分支

1
2
3
4
5
6
7
8
该分支维护最稳定的线上版本，管理整个项目最新的生命周期，每次发版前在生产环境的测试就是在该  
分支进行。
代码来源：hotfix分支、develope版本分支
每次发版打版本基于该分支打版本tag，tag命名规范如：master_7.0.3
备注：开发人员切勿直接提交代码到该分支

develop分支

1
2
3
4
5
6
该分支派生于最新代码master分支，是所有业务线版本迭代共有的分支，保持所有bug修复和本次要  
同时发版的各业务线功能代码
代码来源：各业务线版本分支的合并
备注：避免多业务线同时操作，可由管理人员负责

dev版本分支

1
2
3
4
5
该分支派生于develop分支，是当前业务线版本分支，不同的业务线可以由develop拉取各自的当前版本分支。
代码来源：每个开发人员的feature分支合并或者push
该分支常用于各业务线新功能测试

release分支

1
2
3
4
5
6
7
该分支是预发布分支既所有业务线提测分支，常进行回归测试和兼容性测试
等测试阶段结束，将该分支合并到develop和master上
此处可能很多人会有疑问，已经有了develop分支为什么要有release分支，这个接下来会解释
备注：本次业开发务负责人合并dev版本分支到该分支，避免多人操作

临时分支

feature分支

1
2
3
4
5
6
7
8
9
10
11
该分支是每个负责开发新功能的同学自己由dev版本分支拉取
命名规范：feature-功能命名
建议：如果每个开发人员有很多个功能需求，建议每个功能拉取一个feature，做到功能之间互不干  
扰，相互独立，避免多功能耦合在一起，避免开发中由于变动等因素出现不必要的拷贝、删除等操作风  
险
备注：由于考虑到feature会有很多，远程仓库只维护常驻分支，建议feature分支开发人员始终在  
本地仓库维护，避免push到远端，万一不小心push，那就等feature合并或者push到dev版本分支  
后，自己删除远端分支，至于本地如果自己觉得太多杂乱，可以直接删除

hotfix分支

1
2
该分支是用来在master阶段进行生产环境测试或者灰度时候，发现紧急bug后进行修复，等修复结束  
后合并回develop和master，然后删除该分支

操作流程和常见case操作

流程说明：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1、各业务线负责人从develop分支拉取版本分支dev_x.x.x  
2、各业务线开发同学从dev_x.x.x拉取自己所需数量的本地feature-xxxx
3、开发过程中dev_x.x.x有更新随时fetch并merge到自己的feature-xxx，这样避免好久没有  
merge，突然需要依赖别人代码merge，极有可能会出现大量代码导致conflict（也可以通过fetch   
dev_x.x.x到feature），结束后删除feature
3、开发完某个任务并保证代码能够run起来，然后push代码或者merge到dev_x.x.x
4、当到本业务线提测截止日期，负责人在dev_x.x.x上打包给测试进行新功能测试
5、当新功能结束以后，负责人将dev_x.x.x merge到release分支，进行全app的回归测试
6、等回归结束，负责人将release 同时merge到master和develop
7、在master上进行生产环境测试或灰度，在此期间如果还有紧急重大bug出现，在master拉取  
hotfix分支修复，完成后合并hotfix到master到develop，并删除分支
8、发版本在master上打tag， master_x.x.x，代表线上版本号

常见case：

多业务线并行开发：

1
每个业务线如上流程

多业务线交叉开发

1
2
3
4
5
如果多业务线提测日期不一样，发版时间不一样，如果有依赖前面业务线代码，有两种方式：
 1、等前者merge到develop，然后fetch/merge代码到自己的版本分支 
 2、 将前者新功能测试完成后没问题的版本分支直接merge到自己版本分支

为什么要适用release分支

1
2
3
假如没有release，所有业务线同时操作develop分支，不小心有大量冲突或者需求错误要回溯，当  
此时又有一个业务线要开始建版本分支开发，此时因为develop还没修复耽误别人开发，如果存在  
release就不会影响develop别的业务线开发，所有问题都在release测试分支全部处理

为什么要在本地建feature-xxx

1
2
3
4
如果没有业务组件化，feature-xxx要建本地分支，尽可能不要推到远端，如果误操作，结束可以删  
除远端和本地，这样做好处是：多人直接操作版本分支而造成工程无法run，影响别人开发，尽可能将  
conflict解决在本地feature

总结：

1
2
3
4
1、以上流程可以避免产品需求回溯，增加紧急需求，紧急bug修复，远端代码回溯，多人操作稳定分  
支develop造成无法预估的开发风险
2、切勿直接操作master和develop分支

以上是我大概的一点工作心得，如有不妥之处，望指正