在开发中，不论是一个团队一起开发一个项目，还是自己独立开发一个项目。都少不了要和git打交道。面对不同的开发场景，或许每个团队都有自己的git工作流。这里，我想分享一下我的团队目前正在使用的基于gitlab的git工作流。一起交流一下。
规范化的git流程能降低我们的出错概率，也不会经常遇到git问题，然后去搜一堆git高阶用法。我们的这套git玩法儿，其实只要会基本的git操作就行了，然后规范化操作，基本不会遇到git问题，这样大家就可以将时间用于业务上。最终，希望大家研究git的时候是在感兴趣的时候，而不是遇到问题，紧急去寻找答案的时候
我们的这种git工作流玩儿法呢，主要是分为下面几个分支：
-
master分支 最新的稳定代码 -
vx.x.x分支 版本分支，x.x.x是此次开发的版本号。 -
feat-xxx分支 特性（新的功能）分支 -
fix-xxx分支 修复分支
上面的这些分支呢，就是我们在开发中需要经常去创建并使用的分支。下面详细说说每个分支代表的意思。
master分支代表的是最新的稳定版本的代码，一般是版本分支或者修复分支的代码上线后合并过来的。
feat-xxx分支表示的是为开发某个版本的某个新功能而创建的分支。
vx.x.x代表的是版本分支，这个是我们在每个版本开始前，以此次版本号为名从master创建的分支，比如版本号是 2.0.1，那么版本分支则为 v2.0.1。然后等到该版本的各个新功能在feat-xxx开发完成并冒烟测试通过后，就到gitlab上提一个mr合并到该版本分支上。等到各个环境测试通过后，就将版本分支的代码合并到master上，然后就可以删除本次的版本分支了。
fix-xxx表示的是修复分支，通常在处理线上问题时，创建一个以缺陷名称命名的分支，在缺陷测试通过后，通过mr合并到master分支去
注意：这里有个细节是，在特性分支上开发提交的commit信息，一般认为是无用信息，会在合并给版本分支的时候给合并到一个commit（由于我们是使用gitlab来合并，所以在发起mr请求时勾选squash选项就好了），而在提测后不论是修复测试过程中bug，或者是优化功能的commit则会全部保留，这个目的是一个警示，因为我希望最好的情况是提测即上线，虽然达到这个目标有难度，但是这些留下的commit信息可以帮助我们复盘
各个分支的作用如上面所描述的那样，接着聊聊我们开发的一些经典场景该怎么做：
第一个场景：正常开发迭代
我们以本次需要开发一个 1.0.0版本为例，这个其中有两个功能模块，一个是需要添加一个按钮，一个是需要添加一个表格
sequenceDiagram master->>v1.0.0: 从master切出 v1.0.0 master->>feat-add-button: 从master切出 feat-add-button master->>feat-add-form: 从master切出 feat-add-button feat-add-form->>feat-add-form: 开发完成 feat-add-button->>feat-add-button: 开发完成 feat-add-button->>v1.0.0: 在gitlab发起mr到v1.0.0,并合并所有commit feat-add-form->>v1.0.0: 在gitlab发起mr到v1.0.0,并合并所有commit v1.0.0->>v1.0.0: 提测 feat-add-button->>feat-add-button: 修复测试bug feat-add-button->>v1.0.0: 将修复的 commit cherry pick到 v1.0.0 v1.0.0->>master: 在gitlab上mr到master，并将合并信息改成 v1.0.0
通过上面的时序图，可以看到，我们以我们即将开始的版本命名了一个版本分支 v1.0.0,并且也根据这个版本下面的两个功能创建了两个特性分支 feat-add-button和feat-add-form,然后等功能开发完成后再通过gitlab发起mr（注意，这里要把合并commit选项勾选上）合并到 v1.0.0,那么 v1.0.0分支的代码就会从dev环境开始流转，直到生产环境。这其中，如果有需要修复或者优化的地方，也是先修改特性分支，然后再cherry pick到版本分支上面。上线以后删除版本分支以及下面的特性分支。
通过这个流程管理的代码版本非常清晰，这是截取的master的一部分片段
篇文章是针对git版本控制和工作流的总结，如果有些朋友之前还没使用过git，对git的基本概念和命令不是很熟悉，可以从以下基本教程入手： Git是分布式版本控制系统，与SVN类似的集中化版本控制系统相比，集中化版本控制系统虽然能够令多个团队成员一起协作开发，但有时如果中央服务器宕机的话，谁也无法在宕机期间提交更新和协同开发。甚至有时，中央服务器磁盘故障，恰巧又没有做备份或备份没及时，那就可能有丢失数据的风险。感兴趣的朋友可以过来看看
在正常迭代流程还有个场景。那就是在开发过程中，pm突然过来说，因为某种不可抗力，有一个功能需要砍掉。这个时候，如果是代码还没提测，亦或者是功能比较简单，处理起来还不算麻烦。但如果是，你的功能和其他同事的代码已经在测试了，并且也已经修复了一些bug，commit都交叉在一起，特别是那种涉及修改文件还多的需求，这个时候处理起来就很麻烦，不仅要看着别人的代码，还得警惕自己的代码别弄错了。那这个时候，在我们流程里就很简单，直接删除现有的版本分支就好了，再重新将需要上线的特性分支组合在一起就可以了。可以看到，版本分支是由特性分支组合起来的，也就是说，版本分支可以由不同的特性分支随意组合。这样处理起来就比较方便
第二个场景 线上bug修复
我们以线上需要修复一个按钮的点击事件为例
sequenceDiagram master->>fix-button-click: 从master切出 fix-button-click fix-button-click->>fix-button-click: 修复问题并测试 fix-button-click->>master: 从gitlab发起mr合并到master
其实这里的流程跟上面没多大的区别，但是这里需要注意的是，线上问题修复，一个bug一个commit，合并到master的时候不合并commit。而且需要将合并信息修改为本次的版本号。比如本次则为 v1.0.1
第三个场景 多版本并行开发
这个场景跟正常迭代场景并没啥区别，只是取决于你有多个版本，就创建对应的版本分支就可以了。每个版本分支按照正常迭代流程就可以了。
Q&A
Q：为什么没有使用dev、test等对应环境的分支，这样也好实现push既部署
A：我们这个流程是放弃了使用这些固定的分支的。有几个原因，
代码提测后从dev到test，甚至再到uat（预发布）环境，如果在不同的环境都有代码的变动，那么为了保持这些分支代码一致的话，就需要将代码同步到各个环境分支，这点儿有些费事儿。而版本分支不存在这个问题，版本分支只有一个，可以对应到各个环境。
方便多版本并行开发。版本分支可以创建多个，并行开发的时候比较方便部署到不同的测试环境。如果版本之间的模块关联性不大，还可以并行测试。
语义化。版本分支可以通过分支名称就知道目前有哪些分支正在开发中。
Q: master分支有变动怎么处理
A: master分支有变动的话，及时的合并到自己的功能分支上，以防和其他成员代码有冲突
推荐学习：《Git视频教程》
