• 技术文章 >开发工具 >git

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

    藏色散人藏色散人2023-01-13 15:44:51转载74

    在开发中,不论是一个团队一起开发一个项目,还是自己独立开发一个项目。都少不了要和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视频教程

    以上就是分享一个git工作流优雅的玩法的详细内容,更多请关注php中文网其它相关文章!

    声明:本文转载于:juejin,如有侵犯,请联系admin@php.cn删除
    专题推荐:Git 前端 后端
    上一篇:git怎么合并分支代码 下一篇:自己动手写 PHP MVC 框架(40节精讲/巨细/新人进阶必看)

    相关文章推荐

    • 十月份不可错过的5个GitHub开源项目• 【整理分享】7个有趣又实用的开源GitHub项目• 彻底搞清怎么在GitHub正确检索资源!• 分享一个重要的Git技巧,能保护核心代码!• git怎么合并分支代码
    1/1

    PHP中文网