本文分享自华为云社区《【云小课】应用平台第44课 常用Git工作流推荐》,作者: 应用万花筒. 。
简单来说,工作流就是开发团队预置的开发流程和解决问题时使用的协同约定。合理选择工作流可以帮助团队更好地进行项目管理与版本控制,因此在选择工作流时,需要着重考虑团队情况、规模、项目属性与版本管理计划。
在基于分支的代码管理工作模式中,“Git Flow”在2010年被提出时,便被业界认可并广泛应用,至今仍是经典,它充分发挥了Git分支工作模式的精髓。“Git Flow”工作模式并没有用到复杂的命令和Git底层的结构,是为不同的分支分配一个很明确的角色,并定义各分支之间何时、如何进行交互。类似于经典的瀑布式项目管理模型,“Git Flow”相对庞大复杂,适用于中大型研发团队,在处理复杂的研发项目时使用,项目越复杂、周期越长、需求越动荡,参与者越会感受到这个工作模式的魅力与威力,前往感受经典的魅力!
图1 Git Flow工作模式
提示:
在使用Git Flow工作模式时,业界普遍遵循的规则:
随着软件行业竞争日益激烈,能更快更早的为用户提供新产品特性,俨然成为各企业渴望的核心竞争力之一,敏捷文化随之而生。
当项目经理们在学习、推进敏捷改革时,开发者们也在寻求更简洁的代码托管模式,此时“GitHub Flow”进入了开发者的视线,它上手简单,却非常适配敏捷开发环境,在中小型研发项目中,用“GitHub Flow”刚刚好。
它通常有一个主分支master,随时保持可部署状态,每个新特性或新特性集单独拉一条特性分支,例如feature_1/2/3...,在开发完成后直接在特性分支上进行测试,测试通过的特性分支经过分支合并评审(Merge Request,简称MR)后合并回** master 分支,此模式可以保证 master** 分支随时都是可部署状态。
可见,“GitHub Flow”是以DevOps持续交付为中心的工作模式,使用“GitHub Flow”的团队在实际开发中甚至有一天之内会实施几十次部署的,而支撑这一切的,就是这个足够简洁的工作模式以及华为DevCloud的CodeHub服务、自动化流水线服务。
图2 GitHub Flow工作模式
提示:
在使用GitHub Flow工作模式时,业界普遍遵循的规则:
Git提供了分支这一开发策略后,各种基于分支的代码管理策略就如同雨后春笋般,纷纷被创造出来以应对各样的研发场景,如前文介绍到的适用于大型项目的Git Flow、适用于敏捷开发的GitHub Flow。
那么如果我是个人开发者,亦或者我们是两三人的小微团队,有没有适合我的Git工作模式呢?
当然有,它叫“Trunk Based”,与GitHub-Flow相同,它只有一条长期分支,叫做Trunk或者master即为主干,开发人员之间通过约定直接向被指定为主干的分支提交代码。“Trunk Based”是一种极简的开发模式,它主张一切开发活动都直接在主干分支完成,彻底根除了分支合并冲突的烦恼,并且项目中不会再有那些“你也说不上是干嘛的”分支存在了。因此在个人项目中,这该是最主流的开发模式了。
可以说“Trunk Based”回归了版本控制工具最本源的功能,很好理解也很好上手,对于项目的新进成员,导师不再需要培训复杂的分支定义,只需要告诉新来的“写好的代码记得Commit一下”。
当“Trunk Based”模式中项目需要发布版本时,可以单独拉出一条release分支,也可以直接在主干上发布。
没有了分支的代码隔离,测试和解决冲突都变得简单,同时也鼓励了项目成员进行更加频繁的代码集成和交互。
图3 Trunk Based工作模式
提示:
在DevOps环境中,为了保证正在部署的代码不会被Commit,请灵活使用“锁”,更多了解请前往华为云CodeHub锁定代码仓库功能。
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://huaweicloud.blog.csdn.net/article/details/125555796
内容来源于网络,如有侵权,请联系作者删除!