关于基于git分支开发流程的一点看法

很多公司(软件开发)都采用git来进行管理,git的分布式特性及文件比较(比较文件内容)方式让其优势远大于svn;而在日常开发中基本上都是采用分支开发,这个流程的合理性非常重要;

错误使用例子

很多公司有三套环境,相互隔离:test,pre(预发),product(正式);pre其实就是product的预演,除了功能没正式对外使用,数据库等资源与线上使用是相同的,测试同学通过在pre环境测试即将发布的功能

  • 有些公司在使用分支开发的时候的流程是这样的

    一个新功能开发,从master拉出一个分支A
    开发完成,测试通过,合并到master
    测试通过,直接发布master
    
  • 来看看这个流程有什么问题

    初看没毛病
    再仔细想想,有一个场景,有两个同学在一个项目上开发2个功能,这个时候,两个同学分别拉去了branchA和branchB,
    同学A开发完了,测试环境也ok了,准备上预发测试,这个时候,把代码合并到master,上了预发,上了预发发现有功能遗漏或者有严重bug短时间内不能修复,而同学B的功能需要上线了,这个时候怎么办,只能回滚操作了,各种git操作,把master代码切回到上次发布的代码
    然后B同学继续预发
    
    • 第一个毛病:合并master太随意,如果你在预发的时候,同学C有任务,在这个时候拉了分支出来,进行开发了,如果代码写了很多了,而master又需要回滚,非常混乱
    • 第二个毛病,上了预发的代码要下掉,很麻烦,都是人的手工操作,一不小心直接操作错误,回滚多了,或回滚少了,都是坑(这还是没有上线的操作呢)

思考

1、为什么预发要发master分支呢,master分支不应该是封版的代码码
2、master这么重要的东西,为什么开发人员能随意合并呢,合并操作的时候还是有操作失误的
3、如果大项目预发要占用几天,而又有紧急bug需要上线怎么办(手段很多,但是都是非常规操作)

解决方案

预发不发布master的代码,但是上预发的时候,发布脚本需要自动合并master的代码到分支(不进行push操作),如果有冲突提示出来,开发人员拉下master的代码,合并到开发分支,解决冲突,提交分支代码,继续预发布
任何的开发人员均没有分支合并到master的权限(即不能push master的代码到代码库)
每次预发重新拉去代码,将master代码合并到分支代码进行打包部署
正式发布的时候,才是将分支代码合并到master,部署master项目到product环境,并推送到代码库,纯机器行为,不人工参与master的代码

解决核心问题

1、预发不发布master代码,而是机器脚本将master合并到分支,但是不进行push操作
2、master代码只允许机器脚本来操作(将分支代码合并到master)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值