专栏首页艾小仙痛!痛!痛!我们的好兄弟Git,一路走好!

痛!痛!痛!我们的好兄弟Git,一路走好!

文章是正经文章,标题不要在意,哈哈

Git作为现在主流的版本控制工具,但是如何在软件开发过程中进行合理的分支管理是一个见仁见智的问题。

接下来我会对比下现有的几种比较普遍的分支管理方式和之前在阿里时候使用Aone的区别。

Git Flow

先看一张图片,这张图片来自Vincent在2010年提出的方案,完美的诠释了Git Flow的工作模式。

作为已经提出了10多年的模式,Git Flow相对来说还算是比较简单的。

稳定的分支就两个:develop和master,这两个分支是不会被删除的,master对应稳定的版本,develop则是用于日常开发的稳定版本。

其他的feature、release、hotfix分支都是用完即删。

feature分支是每个人的开发分支,有新的需求都应该基于develop拉出feature分支进行开发。

release分支则是用于测试和发布的分支。

hotfix用于紧急的bug修复。

开发流程如下:

  1. 最开始的时候我们创建好了master分支,然后基于master分支创建出了develop分支
  2. 然后A和B同时基于某个版本的develop分支拉出代码进行开发,分支分别叫做feature-A和feature-B
  3. 如果开发过程中需要修复bug上线,那么就从master拉个分支出来,命名为hotfix-xxx进行修复,修复完成之后合并到develop和master,然后hotfix分支删除
  4. 然后A代码撸的比较快,先一步完成了开发,feature-A分支的代码就合并到develop,feature分支被删除,然后我们基于develop新建一个release-A分支进行测试
  5. 测试过程中如果发现问题那么我们就在release分支修复,把修复的代码合并到develop去
  6. release-A一旦测试完成上线,就把代码合并到master和develop,release分支被删除
  7. 这时候B总算把需求开发完了,然后也按照合并到develop,再新建release-B,合并到master和develop的过程来一遍

对于实际应用也比较简单,对于Mac我们可以直接用最方便的方式进行安装。

首先,安装Git Flow,brew install git-flow-avh,安装好之后执行git flow init就会进行初始化,可以输入你的master和develop分支名字,然后设置其他几个默认分支的前缀。

然后执行git flow feature start irving就可以初始化创建一个feature分支进行开发,默认我们可以看到是基于develop来创建的。

如果开发完成,我们执行命令git flow feature finish irving,然后我们的开发分支就自动合并到了develop,并且开发分支已经被删除。

接着我们的分支需要提测和发布,执行命令git flow release start irving,如果修复bug就直接在这上面修复。

测试完成之后,执行命令git flow release finish irving,代码将会被合并到master和develop,然后分支被删除。

原理和实现方式都说了,那么这个模式其实还是一样的问题,就是他比较适合固定版本的迭代开发,对于互联网不要脸的每天都要发版,每天10几个需求都要上线来说未免太难了。

develop分支我今天有10个需求,8个要上线,2个不上,代码还有先后顺序依赖之类的,这就没法玩好不好,但是他提供了一个比较好的规范和思路。

Github Flow

Github Flow可以说非常简单了,它的提出是在2011年,主要就是针对Git Flow。

它就是基于master分支拉一个分支出来开发,然后可以在新的分支中进行开发,完成之后提交pull request,如果接受之后就合并代码部署了。

图片来自Github官方PDF

具体可以看官方介绍。

这个方式简单是简单,但是在很多公司的业务开发过程中一般都有开发、测试、预发、生产几个环境,没有强有力的工具来支撑,我认为很难用这种简单的模式来实现管理。

我觉得这种模式特别适合小团队,人少,需求少,那就很容易了。

Trunk-Based

这个模型提出的时间更晚一点,是在2013年Paul Hammant提出的方案。

看图基本就能明白,这不就是SVN的模式嘛,主干trunk开发,拉出新的分支进行开发部署、修复BUG。

用过的方案

我们之前用过一个方案,和Git Flow比较类似,但是不依赖工具的支持,更多的是依靠团队本身的约定和规范。

对于开发、测试、预发、生产分别使用分支develop、test、release、master分支,其中master分支作为稳定分支,不能直接提交代码,同时这几个分支是固定唯一的分支。

首先开发阶段,大家都需要基于master创建最新的功能开发分支,命名为feature/xxx。

如果需要发布到开发环境,所有人的代码都需要合并到develop,并且只能用develop分支进行发布开发环境。

如果开发完成,需要提测的分支合并到test分支,那些还在开发阶段的就在develop好了。

测试完成之后需要发布预发(当然叫灰度、uat都行),就把代码合并到release进行发布。

发布完成之后,代码自动合并到master。

这样做的好处就是首先规范了分支的开发和管理,开发中不会产生太多的纠纷,而且对于同时有多个需求开发并且不同时间上线都可以做到很好的管理。

缺点就是一个项目多个需求开发上线,需要合并多次代码,从develop、teest到release都要分别合并一次代码并且解决冲突。

总的来说,这只是一个基于团队的规范,对于环境和中间件CI/CD能力没有太多的要求,可以简单的套用在各个公司的场景。

阿里的解决方案

阿里的解决方案基本上可以说是上面几个模式的一个结合体,称作Aone Flow,可能因为工具本身就叫做Aone吧。

分支只有3个,master分支、功能分支feature、发布分支release,其中release分支基本上是不需要开发人员来参与管理的。

首先,分支的创建也都是基于master,如果有需求,首先创建一个feature分支,部署前Aone会自动合并master代码,所以不用操心代码没有合并的问题,如果存在冲突需要手动解决,反之则就自动生成一个新的分支用于部署,这个分支就是release分支。

来自阿里云效

这个分支可以一直用来发布日常(理解成开发或者测试环境合体)、预发和生产环境。

那如果多个需求同时在开发有冲突不需要合并代码吗?首先,Aone部署可以同时部署多个分支,选择部署多个功能分支代码会自动合并,如果存在冲突需要手动解决,另外可以单独建立一个环境来部署,互不影响,这个功能真是蛮吊的。

这个规则对于预发和生产环境也是同理。

整个开发过程,我们不需要管各种分支,只需要一个feature功能分支用于发布各个环境,最终发布完成之后代码自动合并到master主分支(可选项,也可以不合并)。

整个模式看下来就是集成了各个模式的特点,参考了Git Flow的分支的特点,只不过其他的分支不用开发人员关心,基于主干master拉出分支开发,自动合并又像是TrunkBased的做法,最终整个流程对于开发人员体验下来又像是更简化版的Github Flow了。

文章参考: http://www.brofive.org/?p=2165 https://mp.weixin.qq.com/s?__biz=MzAxNDU0MTE0OA==&mid=2661008528&idx=1&sn=748c3b5bdaa28c3c7b3c06614fd69d47&scene=21#wechat_redirect https://cloud.tencent.com/developer/article/1646937

本文分享自微信公众号 - 艾小仙(aixiaoxianren),作者:艾小仙

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-04-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 深度系统大佬无奈离职,Linux Deepin怕是要凉了

    中兴事件掀起了一股国产风,有利益的地方就有江湖,怕是被领导盯上了。CTO 居然也要被逼得陪喝酒,真是见识了这些老领导们。

    砸漏
  • 周年庆

    所以我现在编写这第366篇文章也是为了纪念这一年的时光,纪念这每天的一篇文章,纪念风里雨里从未间断过的自己,也是为了激励自己既然选择了这条路,就会义无反顾的坚持...

    Fayson
  • 死磕客户价值是ToB公司的生存第一法则

    ? 来源:ToB企业经营|作者:童继龙 ---- 上周参加招商蛇口集团的“年度数字化节”,这是招商蛇口首席数字官徐晓仪总就任以来,用别开生面的方式做的内部数字...

    腾讯SaaS加速器
  • 蹲在ICU的门口,我看到了死亡的样子

    前两天我在 V2EX 上闲逛,看到了看到一个程序员在哭诉,大家赶紧快回去看看自己的父母吧,不然有可能再也没有机会了。

    纯洁的微笑
  • 为什么你做的数据分析,运营懒得看

    做数据分析的最容易和运营怼上。一来运营的数据需求太多,且经常提的很紧急、很奇葩;二来数据分析师主动给的报告往往没人看,运营最喜欢自己跑数自己写报告,还专门衍生出...

    接地气的陈老师
  • 快速助力线上转型 腾讯课堂为“兄弟连”员工提供1V1帮扶方案

    ? 疫情突如其来,对线下机构带来了巨大冲击。曾经被誉为中国最大的PHP培训学校的兄弟连教育,成为第一个在疫情期间正式宣告品牌“破产”的企业。 得知兄弟连教育遇...

    鹅老师
  • 【零基础个人练手项目】小程序云开发实现校园通讯录

    作为一个在校大学生是否遇到过一些事情,有时候我们需要联系学校的一些同学,可能需要找某个社团的部长或是某个专业的同学咨询一个问题,但是关系网复杂,获得同学的联系方...

    用户7118337
  • 万人迷

    他,是一个万人迷。 低调,奢华,有内涵。走在名叫“微信”的大街上,有一万个人能认出他来;放个屁,能让一万个人同时捂住鼻子。 这一天,是公元2015年5月15日,...

    腾讯数据中心
  • 深度 | 中国散伙人

    30多年民企发展路,他们的经历就如电影主角般跌宕起伏,这就是现实版“中国式合伙人”的离合春秋。

    灯塔大数据
  • 【云开发校园技术布道师】tcb-hackthon-alumni-book校园通讯录项目介绍

    韩旭051
  • 【零基础个人练手项目】小程序云开发实现校园通讯录

    韩旭051
  • 分析产品需求背后,程序员引发的思考

    首先带着兄弟们深入了解了一下需求背景,需求简单的几句话,看似不难。做过数据的都清楚,凡是涉及到数据,都多多少少比较难搞。

    一猿小讲
  • 区块链游戏的开发者都是游戏迷?

    区块链游戏——区块链技术诞生的首款杀手级应用。是否知晓区块链游戏,已经成为判断一名游戏玩家是否落伍、过时的标志。显然,作为曾经的游戏迷,区块链游戏...

    陌上花开2018
  • 以通信网络敏捷转型的名义!广东移动 DevOps 标准认证独家揭秘

    11月2日,在深圳召开的 DevOps 国际峰会(DOIS)上,中国移动通信集团广东有限公司获得由中国信息通信研究院(以下简称信通院)颁发的《研发运营一体化(D...

    DevOps时代
  • 互联网大佬打脸史,牛逼也是会吹破的

    2019年4月,马云在一场直播中称996是“修来的福报”,引起舆论哗然,以下是他的原话:

    挖数
  • 为什么说解耦的战术,决定了架构的高度?

    架构设计中,大家都不喜欢耦合,但有哪些典型的耦合是我们系统架构设计中经常出现的,又该如何优化?这里列举了6个点:IP、jar包、数据库、服务、消息、扩容。这些点...

    技术zhai
  • 聊一聊Vue组件模版,你知道它有几种定义方式吗?

    前端组件化开发已经是一个老生常谈的话题了,组件化让我们的开发效率以及维护成本带来了质的提升。

    六小登登
  • 逆袭大厂生存指南-1 初出茅庐

    最近偶然间跟同事一起吃饭聊起了自己做程序员的感受;同事大都是八年左右经验的互联网缔造者;听着他们说起自己一路走来的往事,仿佛在我眼前;仿佛他们最终所说的那个少年...

    我是阿沐
  • 【区块链技术工坊37期】HPB芯链区块链中间件解决方案及落地案例

    2)议题: 区块链是目前国际国内社会很火热的词,但真正的商业化落地之路仍然是在不断的探索之中,还未有大范围的落地应用铺开。为什么会出现这种情况?区块链目前存在...

    辉哥

扫码关注云+社区

领取腾讯云代金券