分享一个git工作流优雅的玩法

学习笔记 03/11 GIT

在开发中,不论是一个团队一起开发一个项目,还是自己独立开发一个项目。都少不了要和git打交道。面对不同的开发场景,或许每个团队都有自己的git工作流。这里,我想分享一下我的团队目前正在使用的基于gitlabgit工作流。一起交流一下。

规范化的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

6526b7836e7471605798813eaed3e62.jpg

通过上面的时序图,可以看到,我们以我们即将开始的版本命名了一个版本分支 v1.0.0,并且也根据这个版本下面的两个功能创建了两个特性分支 feat-add-buttonfeat-add-form,然后等功能开发完成后再通过gitlab发起mr(注意,这里要把合并commit选项勾选上)合并到 v1.0.0,那么 v1.0.0分支的代码就会从dev环境开始流转,直到生产环境。这其中,如果有需要修复或者优化的地方,也是先修改特性分支,然后再cherry pick到版本分支上面。上线以后删除版本分支以及下面的特性分支。

通过这个流程管理的代码版本非常清晰,这是截取的master的一部分片段

image.png

在正常迭代流程还有个场景。那就是在开发过程中,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工作流优雅的玩法的详细内容,更多请关注本站点其它相关文章!

本文地址:https://www.stayed.cn/item/26749

转载请注明出处。

本站部分内容来源于网络,如侵犯到您的权益,请 联系我

我的博客

人生若只如初见,何事秋风悲画扇。