成熟的 Git 分支模型

原创
2018/12/19 21:47
阅读数 3.1K

公众号原文: 成熟的 Git 分支模型

今天介绍一下工作中会用到的 Git 分支模型。

先贴上图以表敬意

gitmodelpng

闲言

在学校不管是自己写课程设计还是给老师做项目,有 2 到 3 个人一起协作开发时就会使用 Git ,但是只是简单用了它所提供的代码协作功能,在学校的项目,比如课程设计,开发完老师检查完就没有维护了,给老师做项目也是,基于项目的特征:没有持久性、一次性开发,所以没有应到 Git 分支模型。在企业中,一个应用往往是有比较长的生命线,由很多个迭代项目开发构成,这时要解决几十甚至几百人的代码协作问题,就需要一套完整的规范的代码开发流程。

我还记得当初大四的时候,去了一家企业实习,当时小团队只有 3 个开发人员,git 使用没有规范,只有一个 master 主分支,项目也没有管理规范,来一个需求点就做。当时经常出现代码覆盖,各种代码合并,线上代码也不知道是哪个节点的代码。。。到我走的时候,也没使用上这个分支模型。毕业后入职了某银行,不说分支模型了,Git 都没用上,直到今年跳槽到互联网公司才了解到这个分支模型。因此,你工作不一定会真正用到这个分支模型,如果是在互联网企业,很有可能会使用上。

有些小伙伴看到这张偌大的图觉得有些晕,很认真地说,这是一张大家都在用的图,特别是互联网企业。如果是还没有工作的小伙伴,可能有些陌生,没事,我们来看一下这些内容。

分支介绍

master :这个分支的代码是发布到生产的代码

develop :这个分支的代码是预发布到生产的代码

release :这个分支的代码是新版本发布到生产的代码

feature :这个分支的代码是新需求开发的代码

hotfix :这个分支的代码是紧急修复生产 bug 的代码

场景设想

下面列举一些可能你在工作中会经常面对的场景

  1. 组长分配新需求下来,安排下周上线(假设是 1227 号),你看看当前有没有下周版本的分支?有的话很简单,checkout 下周分支(feature_app1.1.0_1227)来开发就行,没有的话这时需要新建分支,从 develop 分支创建新的 feature 分支(feature_app1.1.0_1227),然后将对应的 pom.xml 版本号修改成 1.1.0-SNAPSHOT,注意命名,比如这里我用 feature 做前缀,你也可以自己设定一个规则。

  2. 开发完 feature_app1.1.0_1227 需求,移交了测试,很遗憾,测试出现了 n 个 bug,这时依旧在 feature_app1.1.0_1227 上修复 bug。

  3. 终于到了发版前一天,测试 MM 说 n 轮测试完了,没问题,拉上线版本,再做一次回归测试。这时,你就需要把 feature_app1.1.0_1227 分支合并到 develop 分支,然后从 develop 分支中创建新的分支 release_app1.1.0_1227,然后修改对应的版本号为 1.1.0-RELEASE。

  4. 到了发版日早上了,测试 MM 用了 release_app1.1.0_1227 版本测试了一番,又发现了一个 bug。别慌,只要不是生产的 bug,都好解决。这时你要在 release_app1.1.0_1227 修复 bug,切记不能在 feature_app1.1.0_1227 上修改,feature_app1.1.0_1227 分支已经没有多大作用了,只用来看代码提交记录。

  5. 安安全全的到了晚上,开始发版了,发完版突然发现了有异常,定位问题后发现是有一行代码写错了,跟组长确认后,在 release_app1.1.0_1227 分支上做了修改,重新打包后发版,验证了一段时间,没问题了。。。

  6. 发版总算完成了,这时,别忘记把 release_app1.1.0_1227 版本合并到 develop 和 master 分支。还有一点很重要的,把 develop 分支代码合并到 1227 以后的版本(如果已经有1227 以后的版本的话)。注意:这个步骤合并代码要谨慎,如果有别人的代码合并冲突比较大,需要找那个开发的同事一起合并代码。总算可以睡个好觉了。。。

  7. 告别了旧需求,迎来了新需求,接下来的需求开发就按上面的步骤走。。。

  8. 第二天,突然生产上一直报 NullPointerException,定位发现是一行代码没有判空导致的,三番确认,原来这个数据以前是不为空的,现在确实需要支持有些数据为空的,需要紧急修复这个 bug,和组长确认之后,从 master 分支上拉了一个 hotfix_app1.1.1_1228 分支代码,修复了 NullPointerException,打包后上线,验证没问题后,把 hotfix_app1.1.1_1228 分支合并到 develop 和 master 分支,并把 develop 分支合并到 1227 以后的版本。

好了,一大坨的文字描述了基于分支模型开发的过程。不同公司在应用过程中可能会有些微小的不同,但是整体流程都是差不多的。比如有的公司可能会把 release 合并到 master 后,用 master 代码发布到生产,发版当时有异常,再从 master 分支上拉 hotfix 分支进行修复。上面描述的步骤就不一样了,发版时出现异常,直接在 release 上修复。这些小的差别就不用计较太多啦。

希望本文能够让你认识到有这么一个标准的 Git 分支模型,在不管工作上还是学习上,在需要分支管理的时候,回忆起有这么一个图,根据你的场景再应用进去,肯定会少走很多弯路。

推荐阅读:

行为型模式:责任链模式

行为型模式:模板方法

最近在写设计模式系列文章,感兴趣的同学可以关注公众号:LieBrother,第一时间获取文章推送阅读,也可以一起交流,交个朋友。

公众号

展开阅读全文
打赏
7
135 收藏
分享
加载中

引用来自“云南老司机”的评论

引用来自“久永”的评论

识其皮,不识其髓。
“书读大略”,不是每个人都能做到的。

怎么哪里都有你
是的!有计算机,有网的地方就会有我幽灵。。。
2019/03/09 19:56
回复
举报
LieBrother博主

引用来自“全体人员”的评论

为啥不用tag呢?我们是这么操作的,开发在dev-xxx分支(可能有多个功能在并行开发),master放线上代码(方便查阅),每次发版本从dev-xxx拉出来一个v1.2.x这样的分支进行合代码(多版本并行开发),然后在v1.2.x上面打tag,发布(测试版本也一样)。版本正式上线后,把v1.2.x合并到master。
合适就好,我们这边参考 git flow 去做的
2019/03/08 23:29
回复
举报
LieBrother博主

引用来自“久永”的评论

识其皮,不识其髓。
“书读大略”,不是每个人都能做到的。
如果有哪些地方说得不好欢迎指出,这么笼统说不太理解
2019/03/08 23:28
回复
举报
LieBrother博主

引用来自“ZeroneLove”的评论

和我们公司目前是用的分支模型完全一样
哈哈,都是参考 git flow
2019/03/08 23:27
回复
举报
LieBrother博主

引用来自“javaxiaoz”的评论

没用过分支,就一个猪肝
适合就好
2019/03/08 23:25
回复
举报
LieBrother博主

引用来自“不空”的评论

可以试试git flow😊
嗯嗯,就是参考 git flow 的
2019/03/08 23:24
回复
举报
LieBrother博主

引用来自“黄正文”的评论

适合自已的就好
是的,各有各适用的场景
2019/03/08 23:24
回复
举报
适合自已的就好
2019/03/08 20:20
回复
举报

引用来自“云南老司机”的评论

引用来自“久永”的评论

识其皮,不识其髓。
“书读大略”,不是每个人都能做到的。

怎么哪里都有你

@云南老司机 哈哈哈 他估计是个键盘侠 杠精
2019/03/08 18:55
回复
举报
可以试试git flow😊
2019/03/08 16:59
回复
举报
更多评论
打赏
16 评论
135 收藏
7
分享
返回顶部
顶部