【云小课】应用平台第44课 常用Git工作流推荐

应用万花筒. 发表于 2022/06/29 17:52:25 2022/06/29
【摘要】 相信大部分的开发人员天天都在用Git,在实际工程中,遵循一个合理、清晰的Git使用流程,是非常重要的。否则,每个人都提交一堆杂乱无章的Commit,项目很快就会变得难以协调和维护,这里就需要工作流来规范整个项目开发流程,今天就带大家一起去了解工作流是什么?

1. Git工作流—动静有法

简单来说,工作流就是开发团队预置的开发流程和解决问题时使用的协同约定合理选择工作流可以帮助团队更好地进行项目管理与版本控制,因此在选择工作流时,需要着重考虑团队情况、规模、项目属性与版本管理计划。

云小课原图.jpg


2. 华为开发者常用的工作流

表1 华为开发者常用工作流模式

Git工作流模式

特性概要

适用团队规模

Git Flow

  • 经典工作模式

  • 复杂但严谨

  • 内耗大但安全稳定

  • 全流程可控可追溯

20人以上

GitHub Flow

  • 基于分支合并评审的工作模式

  • 重视小团队的线上合作

  • 适用于敏捷开发及DevOps

5~20人

Trunk Based

  • 仅使用一条Trunk分支

  • 简约的工作模式

  • 规避合并冲突

  • 适用于个人项目、敏捷开发及DevOps

5人以下


3. Git Flow—经典永不过时

在基于分支的代码管理工作模式中,Git Flow在2010年被提出时,便被业界认可并广泛应用,至今仍是经典,它充分发挥了Git分支工作模式的精髓。Git Flow工作模式并没有用到复杂的命令和Git底层的结构,是为不同的分支分配一个很明确的角色,并定义各分支之间何时、如何进行交互。类似于经典的瀑布式项目管理模型Git Flow相对庞大复杂,适用于中大型研发团队,在处理复杂的研发项目时使用,项目越复杂、周期越长、需求越动荡,参与者越会感受到这个工作模式的魅力与威力,前往感受经典的魅力!

图1 Git Flow工作模式

表2 Git Flow工作模式中分支的使用建议

分支名

描述

有效性

何时被创建

何时直接在此分支上开发

何时被其它分支合入

何时合入到其它分支

何时结束生命周期

master

核心分支,配合标签,用于归档历史版本,要保证其中的版本都是可用的

长期存在

项目仓库建立之初

-

  • 项目版本封版时,被develop或release分支合入

  • 已发布版本中发现的bug被修复后,被对应的hotfix分支合入

-

-

develop

开发主分支,用于平时开发的主分支,应永远是功能最新最全的分支

长期存在

在master分支被创建之后

一般不建议

  • 新特性开发完成后,feature分支合入到此分支

  • 当项目启动开发一个新版本时,被上一次历史发布版本(release或master)合入

  • 当要发布版本时,合入到release分支

  • 当需要归档版本时合入到master分支

-

feature_1/2/3...

新特性开发分支,用于开发某个新特性,可以几条并行存在,每条对应一个或一组新特性

临时

  • 收到新特性任务时,基于develop分支创建

  • 当正在开发的新特性任务被拆分出子任务时,基于对应的母feature分支创建

当被创建出来,开始开发新特性时

子feature分支开发、测试完成后,会合入到母feature分支

当该分支上的新特性开发、测试完成时,合入到develop分支

其对应的特性已经验收(发布、稳定)后

release

发布分支,用于检出某个要发布的版本

长期存在

项目首次发布前,基于develop分支创建

-

当需要发布一个版本时,被develop分支合入

  • 当完成一次版本发布,将该版本归档时,合入到master分支

  • 当要基于某一个发布版本,开始开发一个新版本时,合入到develop分支,起到初始化版本的作用

-

hotfix_bug1/bug2...

快速修复分支,用于当现网版本发现bug时,拉取出来单独用于修复这些bug的分支

临时

当master、bug版本中发现问题时,基于对应版本(一般是master分支)创建

当被建立出来时

-

当其对应的bug修复任务完成时,会将其作为修复补丁合入master、develop分支

其对应的bug修复,已经验收(发布、稳定)后

在使用Git Flow工作模式时,业界普遍遵循的规则:

  • 所有开发分支从develop分支拉取。

  • 所有hotfix分支从master分支拉取。

  • 所有在master分支上的提交都必须要有标签,方便回滚。

  • 只要有合并到master分支的操作,都需要和develop分支合并,保证同步。

  • master分支和develop分支是主要分支,都是唯一的,其它派生分支每个类型可以同时存在多个。


4. GitHub 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工作模式

表3 GitHub Flow工作模式中分支的使用建议

分支名

描述

有效性

何时被创建

何时直接在此分支上开发

何时被其它分支合入

何时合入到其它分支

何时结束生命周期

master

核心分支,配合标签,用于归档历史版本,随时保持可发布/部署的状态

长期存在

项目仓库建立之初

-

当特性分支feature_1/2/3...测试通过后,合入到master分支

-

-

feature_1/2/3...

新特性开发分支,用于开发某个新特性或新特性集

临时

收到新特性任务时,基于master分支创建

当被创建出来,开始开发新特性时

-

当该分支上的新特性开发、测试完成时,合入到master分支

其对应的特性已经验收(发布、稳定)后

在使用GitHub Flow工作模式时,业界普遍遵循的规则:

  • 让master分支总是保持可以部署的状态。

  • 进行新特性或新特性集开发时要从master分支创建新的分支,新分支名称要具有描述性。

  • 新特性分支的Commit一般在本地仓库进行,当需要合并回master分支时,推送到远程仓。

  • 新特性分支合并回master分支前需要进行测试、评审与充分的交流,要确保合并后的master分支可用且经测试。

  • 与master分支合并后,即可立即部署,使线上版本符合预期。


5. Trunk Based—归本固源

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锁定代码仓库功能

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:cloudbbs@huaweicloud.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。