你选择合适的git workflow了吗?

前言

之前和大家介绍过测试同学在工作工程中常用到的git命令,今天想和大家谈谈git workflow方式,同时基于项目实际情况,我们的最后选择。

工作流程重要性

工作流程规范会让大家感到束缚,但是大家还是都愿意遵守,因为大家知道一个真理:如果没有严谨规范的项目工作流程,无法成功创建一款优秀的产品。在使用git对项目版本进行管理,就需要了解git常用的工作流形式,并依据自己的实际情况选择适合的方式。 Git workflow常见的形式有:

  • Centralized Workflow,集中式工作流
  • Feature Branching Workflow,分支工作流
  • Gitflow Workflow,Gitflow工作流
  • Forking Workflow,ForKing工作流

Centralized Workflow

Centralized Workflow和subversion一样,将中央仓库作为项目中所有修改的唯一入口。和svn中的trunk不同,默认的开发分支叫做master,所有更改都被提交到这个分支。这种工作流不需要master之外的其它分支。开发过程快速简单。

优点:

  • Centralized Workflow整体过程快速简单;
  • 对于从SVN方式轻易过来的团队可以减少适应时间和成本;

缺点:

  • 不熟悉的新手加入团队就可能是代码库频繁搞乱出现问题;

适用场景:

  • 团队人数少
  • 开发不是很频繁
  • 团队沟通方便
  • 不需同时维护多个版本

Feature Branching Workflow

Feature Branch Workflow和Centralized Workflow相比,在开发每个功能时都会重新创建一个独立的分支而不只是使用master分支。由于每个分支是独立且互不影响,任何推向master 分支的 feature-branch 都经过代码审核和验证。这就意味着主分支不会包含broken code,对持续集成环境是很有帮助的。

优点:

  • 添加code review,代码质量有一定保障;
  • 可以同时多个功能需求进行同步开发;
  • 问题响应速度快捷;

缺点:

  • 不利于配合团队工作,无法对分支分配分配明确的目的;

适用场景:

  • 开发团队相对固定,而且有一定规模
  • 多个功能,多个问题并行开发
  • 对code review有较高要求
  • 更注重团队效率

Gitflow Workflow

与Feature Branch Workflow比起来,Gitflow workflow并没有增加任何新的概念或命令。其特征在于为建立不同的分支并明确的角色,并且定义了使用场景和用法。除了用于功能开发的分支,它还使用独立的分支进行发布前的准备、记录以及后期维护。 这套工作流讲究的是平稳,有序,Git-flow工作流在 Git 分支标签等概念的基础上,添加了Feature,Release,Hotfix 等概念,用以精确描述代码版本控制的一些流程,所有协作者在放弃一些个人效率的基础上,统一开发流程,最终带来的是整体的规模化的团队的整体效率提升。

优点:

  • 添加code review,代码质量有一定保障;
  • 可以同时多个功能需求进行同步开发;
  • 每个分支的角色更为明确;

缺点:

  • 上手较难一点,需要一些基础知识培训;

适用场景:

  • 接受额外学习Git-Flow的成本
  • 有专门的代码仓库管理员
  • 开发团队相对固定,而且有一定规模
  • 常常有并行开发需求
  • 团队对于Release,Bug,Feature这些概念有统一定义标准的

Forking Workflow

Forking Workflow与以上讨论的工作流很不同,一个很重要的区别就是它不只是多个开发共享一个远程仓库(central repository),而是每个开发者都拥有一个独立的服务端仓库。也就是说每个contributor都有两个仓库:本地私有的仓库和远程共享的仓库。

优点:

  • 任意开发者均可以参与项目,而不需要每个人都推送到单一的中央仓库。而管理者选择性的接受任何开发者的提交,却不需要给他们中央仓库的权限。

缺点:

  • 对于职能分工明确且不对外开源的团队暂无很好的优势;

适用场景:

  • 适用于开源项目
  • 开发者有衍生出自己的衍生版的需求
  • 开发者不固定,可能是任意一个自由开发者

我们的选择

上述不同的工作流方式各有利弊,大家可以根据项目实际的需要作出符合自己的选择。 以小编负责的其中两个项目为例: 项目一: server端新项目,开发人数2人,测试1人,完成开发上线后预测未来逻辑变更频率较低。负责的团队之前使用SVN进行版本控制。 我们的选择: 基于项目的现状和投入收益的考量,该项目我们采用CentralizedWorkflow的方式。 项目二: 内核相关项目,开发人数较多,工作流需要同时满足QA,shell层开发,内核开发,线上业务的需求,codereview执行规范,开发需求量大且团队成员均对git工作流程有熟练经验。 我们的选择: 基于项目业务的需求,我们采用Gitflow workflow的方式。同时将工作流尽可能的简化,提高核心工作的效率。在分支的管理上,我们建立三个分支:dev、beta和release,并明确相关的代码提交流程规范。工作流参考示意图如下:

备注:示例图参考rubygarage.org,项目二中dev,beta,release分支分别对应图中的development,release, master分支。

最后

基于项目实际情况,目前我们选择的工作流方式均符合我们当前的需求。在后期如果存在项目形态的变化,可以相应的调整变更工作流方式。

本文分享自微信公众号 - 搜狗测试(SogouQA)

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

原始发表时间:2019-07-04

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏娱乐心理测试

程序员经常访问的技术网站

(1).Github 代码托管 GitHub的使用可是程序员在职业生涯中技能必不可少的技能。它可以做Git代码托管平台,很多开源项目都放在Github上,因此...

24650
来自专栏SimFAS中控

SimFAS中控iPad控制电脑开关机实现方法

24700
来自专栏Objective-C

Sourcetree

会有下面这种提示,点击确定就好了。再次进行拉取或推送时就不需要再输入账号和密码了。

21240
来自专栏宜信技术实践

iOS开发如何避免安全隐患

现在很多iOS的APP没有做任何的安全防范措施,导致存在很多安全隐患和事故,今天我们来聊聊iOS开发人员平时怎么做才更安全。

12220
来自专栏京程一灯

给用户一个否减弱动画效果的选择[每日前端夜话0x8B]

你有没有看到过这样一种简洁的技术【http://bradfrost.com/blog/post/reducing-motion-with-the-picture...

10650
来自专栏音视频技术

CAE+VBR如何提升用户体验?

文 / Pratima Ashok Dhuldhule & Darshan Datt K. S.

11820
来自专栏木二天空

006.Ceph对象存储基础使用

Ceph 对象网关是一个构建在 librados 之上的对象存储接口,它为应用程序访问Ceph 存储集群提供了一个 RESTful 风格的网关 。

23160
来自专栏前端词典

10 种 JavaScript 最常见的错误

查看了数千个项目后,发现了 10 个最常见的 JavaScript 错误。我们会告诉你什么原因导致了这些错误,以及如何防止这些错误发生。如果你能够避免落入这些 ...

9720
来自专栏一“技”之长

iOS开发之ExternalAccessory框架的应用

ExternalAccessory框架用来对外设进行管理,iOS外设通常是通过MFI认证的外部设备,可以通过蓝牙进行连接,也可以使用lighting...

22620
来自专栏音视频技术

李磊:从底层研发“敦煌”让我受益匪浅

LiveVideoStack:李磊你好,简单介绍下自己的工作经历,以及在美摄负责的工作内容和专注的领域。

6130

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励