你们公司分支策略是什么样的

本文转载自微信公众号「虞大胆的叽叽喳喳」,作者虞大胆  。转载本文请联系虞大胆的叽叽喳喳公众号。 

创新互联公司专注于企业营销型网站建设、网站重做改版、南沙网站定制设计、自适应品牌网站建设、H5场景定制商城网站建设、集团公司官网建设、外贸网站制作、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为南沙等各大城市提供网站开发制作服务。

在基于git的工作流中,master一般是做持续集成的,开发人员在特性分支开发,经过测试后,就会merge到master做集成测试,测试通过就表示master可部署了。

可现实情况下,特性分支自测没问题,不代表就真的没问题,测试人员还没测试呢,所以此时的master分支其实是没准备好的(从master特定commit id到生成分支其实是有一定难度的)

我们目前的做法,在master分支之前还有一个SIT系统集成分支,也就是说这个分支是专门给QA人员测试的,测试没问题后,将特性分支的代码合并到pre分支,仿真环境如果没问题,再将特性分支合并到master分支,然后进行发布。

SIT分支相当于做集成测试了,保证了master的代码是相对可靠的。

那什么代码合并到SIT分支呢?不管几个项目,也不管这些项目具体的上线时间,特性分支都可以合并到SIT分支,然后统一给QA人员测试(相当于提前测试多个项目了),正因为这样,上线的时候无法从SIT分支merge到master分支。

这种工作流多了一个步骤,必然会有副作用,首先merge到SIT分支的时候,如果有冲突,SIT分支不应该解决冲突,因为SIT分支只是为了测试,不会上线的,所以不应该解决冲突;其次很多人说为了避免有冲突,那么我就经常性的将SIT分支上的代码merge(也就是pull)到特性分支,这也非常不好,因为这个特性分支就不隔离了。所以正确的做法,如果merge到SIT分支产生冲突,应该自己去解决冲突,可如何找到和那个分支冲突呢?

还有SIT分支和master分支因为时间点和作用不一样,没有必要保持代码是同步,可pre分支和master分支理论上应该保持同步,上线的时候没有选择merge SIT分支到master分支的原因是cherry-pick还是有一定复杂度的,merge特定commit id也是有复杂度的,所以我们选择从特性分支合并到master,那必然要思考一个问题,pre分支测试通过代表master分支测试通过吗?如果pre到master是一个fast forward,理论上不用再重复测试。

还有一种做法和我们的做法类似,就是有一个隐形的SIT分支,特性分支一旦提交到远端,就自动merge到SIT分支,查看是否有冲突,如果有冲突,就提醒开发者去解决,从而保障能够持续集成。

最后说说特性分支,我们还喜欢根据迭代周期去弄一个大分支,实际上这个大分支包含了很多子功能,也就是说可以拆分为多个子分支,那这两种方式有什么优缺点呢?

如果在一个大分支,能够减少一些冲突,但做不到隔离了,如果频繁的pull,是选择merge还是rebase呢?应该选择merge,推送到远端的分支不建议做rebase,会产生很多问题。其实既然选择了一个大分支,那git历史记录必然会很难看的,基本没有追朔性。如果实在要使用一个大分支,建议不要太频繁的提交到远端,尽量做好自测再提交。SIT部署的环境(QA)是为了测试人员测试的,应该保障一定的稳定性,它们不是给开发人员调试用的。

建议还是子分支,一方面说不定有一天就上线部分功能,子分支就合适了;另外子分支也能做到隔离;当然可能会遇到很多merge冲突的问题,这时候就需要自己甄别与那个分支发生冲突了(目前没有想到办法)。

git工作流有多种选择,主要看整个团队对git的理解程度,并行项目数量,CI/CD方式等等,没有绝对的好坏,只要能说得通,没有明显的缺点,那就是好的工作流。

网站栏目:你们公司分支策略是什么样的
网页链接:http://www.gawzjz.com/qtweb/news47/208297.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联