Git分支管理策略是什么
本篇内容介绍了“Git分支管理策略是什么”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
创新互联凭借在网站建设、网站推广领域领先的技术能力和多年的行业经验,为客户提供超值的营销型网站建设服务,我们始终认为:好的营销型网站就是好的业务员。我们已成功为企业单位、个人等客户提供了网站设计、成都网站设计服务,以良好的商业信誉,完善的服务及深厚的技术力量处于同行领先地位。
使用git带来的分支疑惑
git
为什么好,为什么要用 git
,这不是我本文想要说明的问题。
这里想要给大家分享一下自己使用过程中产生的疑惑,以及解决的这些疑惑的过程。话又说回来,我现在依然充满疑惑。真不知道30岁的时候会不会不惑。
在使用 git
过程中,它的分支功能让我真的欣喜若狂,不过这是把双刃剑,一不小心你会得到这种git
路径图:
图片来源:阮一峰老师博客
我的疑惑:
那么团队中我们该使用怎样的分支策略来进行开发协作?
在多人的团队中,我们应该在
master
分支上直接开发吗?如果线上产生了bug该通过什么样方式的分支去修复?
当有多个分支的时候,测试如何有效的参与进来每一个分支的测试?
用成熟的工作流来解决问题
在解答上面的疑惑前,先介绍几个工作流,然后通过工作流的模式,来进行解答。因为我们必须在某种设定的情景下,才能讨论解决问题的思路。
下面三种工作流方式,都是采用功能驱动开发,也就是先有需求产生,然后诞生对应的分支,然后开发,最后合并回来,完成使命被删除。
Git flow
Github flow
Gitlab flow
关于这三种工作流的详细介绍,建议看看这篇文章-阮一峰
我现在采用的是 Git flow
,经过自己的实践,确实好用,解决不少问题。然后如果发现与自己的实际情况有些出入,可以根据需求做出些变动调整。
我的选择
我选择了 Git flow,它的主要特点是,长期存在两个分支:
主分支master
开发分支develop
然后,存在三种辅助分支,都是短期的,并且一半情况下只应该存在本地,不要提交到远程库。
功能分支(feature branch)
补丁分支(hotfix branch)
预发分支(release branch)
在进行上面的分支时,建议的命名规范:feature-xxx、release-xxx、hotfix-xxx
话外:我以前喜欢用下划线,后来发现打中线不需要按
shift
,哈哈,从此开始中线时代。
什么时候要功能分支?
当你拿到一个需求,或者不是一个立马需求上线的bug修复,那么就应该从 develop
开一个分支出来,完成这部分工作。完成后合并到 develop
分支。
什么时候要预发分支?
这个分支是为预发准备的,测试的介入,也只应该在该分支产生时才介入。当我们不管是新功能开发,还是一般的bug修改都差不多了。就应该从develop
产生一个release
分支,交给测试,如果有bug直接在上面修改。全部完成后,合并回develop
,并且合并到master
。
关于这个分支我得再多说几句。因为这是非常重要的一步,如果我们使用了 git 钩子,当合并到 master
的时候,会自动发布到线上,所以这是临上线的最后一道屏障。
同时这里也解决了我一个疑惑,测试如何参与到git
的每个分支中来?答案是:测试不应该参与到每个分支中来,只应该参与到release
分支中去。其它的开发分支,都应该由开发人员自己测试,测试没有问题的时候才准许合并到develop
,这就要求每一个开发要提高自己交付的产品质量,如何确保自己交付的产品质量?自动化测试是个不错的选择,好了,打住,这不是咋们今天的主要任务,这个话题改天再聊。
什么时候需要补丁分支?
这种情况越少越好。因为它产生的原因是:线上出了bug,并且必须马上修复,不管你身在何方,当手机响起,拿出电脑改bug吧。
它与release
很像,都需要完成后,同时合并到:master
与develop
。不同的是,它需要从master
上开一个分支出来。
注意这里没有测试的介入,一半来说都是代码上某一个小的紧急bug,虽然很严重,但是可以很容易改动。当然如果有一些例外情况,应该让测试进行测试后再合并、发布。
“Git分支管理策略是什么”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!
分享文章:Git分支管理策略是什么
文章转载:http://scyanting.com/article/gjcpcp.html