团队协作的三大工作流

团队协作的三大工作流

Git 作为一个代码版本管理系统,利用它强大的版本控制和branch,我们能做出一些优雅的团队协作的工作流。

这也是之前我在Git文章谈到的,Git对团队协作具有很大帮助,这篇文章我将来谈谈基于Git的三大工作流。

工作流 在英语中叫做:workflow,从名字上看出团队协作应该像流水一样,顺畅。

  • 好的工作流能给你团队合作带来很大的好处,有条不紊的应对各种问题。
  • 坏的工作流可能会使本来一个很好的项目失败在团队协作上。

所以我们来学学程序员常用到的工作流。

flow

现在三种广泛使用的工作流程:

  • Git flow
  • Github flow
  • Gitlab flow

如果你对Git还不是很熟悉,可以先阅读下面的文章。


一、功能驱动

本文的三种工作流程,有一个共同点:都采用 “功能驱动式开发”(Feature-driven development,简称FDD)。

它指的是,需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该分支就合并到主分支,然后被删除。

二、Git flow

最早诞生、并得到广泛采用的一种工作流程,就是Git flow,相对来说是复杂度较高的,可以看到下面这张图片:

Git Flow

2.1 特点

从上面这张图片可以看到,它最主要的特点有两个。

工作流特点

首先,项目存在两个长期分支。

  • 主分支master
  • 开发分支develop
  1. master用于存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的分布版;
  2. develop用于日常开发,存放最新的开发版。

其次,项目存在三种短期分支。

  • 功能分支(feature branch)
  • 补丁分支(hotfix branch)
  • 预发分支(release branch)

所谓短期分支就是,基于功能,补丁,预发布,一旦完成开发,它们就会被合并进developmaster,然后被删除。

2.2 优缺点

Git flow的优点是清晰可控,缺点是相对复杂,需要同时维护两个长期分支。

大多数工具都将master当作默认分支,可是开发是在develop分支进行的,虽然让逻辑更清晰,但这导致经常要切换分支,有一定的复杂度。

但更大问题在于,这个模式是基于”版本发布”的,目标是一段时间以后产出一个新版本。但是,很多网站项目是”持续发布”,也就是说如果我发布版本的频率很高,代码一有变动,就部署在master一次。这时,master分支和develop分支的差别不大,没必要维护两个长期分支。

所以根据具体项目情况,选择合作方式。

三、Github flow

Github flow 是Git flow的简化版,专门配合”持续发布”。它是 Github.com 使用的工作流程,也同时是参加开源项目的主要合作方式之一。

Github工作流

3.1 流程

它只有一个长期分支,就是master,因此用起来非常简单。

定义:

  • 合作的仓库:我称之主仓库;

  • 个人fork之后的仓库:我称之为子仓库。

官方推荐的流程如下。

Github工作流

预处理:先从主仓库fork出一个子仓库。

第一步:根据需求,从子仓库的master拉出新分支,不区分功能分支或补丁分支。

第二步:新分支开发完成后,或者需要讨论的时候,就向中央仓库的master发起一个pull request(简称PR)。

第三步:Pull Request既是一个通知,让别人注意到你的请求,又是一种对话机制,大家一起评审和讨论你的代码。对话过程中,你还可以不断提交代码。

第四步:你的Pull Request被接受,合并进master,重新部署后,原来你拉出来的那个分支就被删除。(先部署再合并也可。)

3.2 评价

Github flow 的最大优点就是简单,对于”持续发布”的产品,可以说是最合适的流程。

问题在于它的假设:master分支的更新与产品的发布是一致的。也就是说,master分支的最新代码,默认就是当前的线上代码。

可是,有些时候并非如此,代码合并进入master分支,并不代表它就能立刻发布。比如,苹果商店的APP提交审核以后,等一段时间才能上架。

这时,如果还有新的代码提交,master分支就会与刚发布的版本不一致。

另一个例子是,有些公司有发布窗口,只有指定时间才能发布,这也会导致线上版本落后于master分支。

上面这种情况,只有master一个主分支就不够用了。通常,你不得不在master分支以外,另外新建一个production分支跟踪线上版本,即在等待中进行继续开发。

不过上面所说的情况不是所有项目都能遇到的,根据实际情况随机应变很重要

四、Gitlab flow

Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点,既有适应不同开发环境的弹性,又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。

Gitlab

4.1 上游优先

Gitlab flow 的最大原则叫做”上游优先”(upsteam first),即只存在一个主分支master,它是所有其他分支的”上游”。只有上游分支采纳的代码变化,才能应用到其他分支。

4.2 持续发布

Gitlab flow 分成两种情况,适应不同的开发流程。

持续发布

对于”持续发布”的项目,它建议在master分支以外,再建立不同的环境分支。比如,”开发环境”的分支是master,”预发环境”的分支是pre-production,”生产环境”的分支是production

开发分支是预发分支的”上游”,预发分支又是生产分支的”上游”。代码的变化,必须由”上游”向”下游”发展。比如,生产环境出现了bug,这时就要新建一个功能分支,先把它合并到master,确认没有问题,再cherry-pickpre-production,这一步也没有问题,才进入production

只有紧急情况,才允许跳过上游,直接合并到下游分支。

4.3 版本发布

版本发布

对于”版本发布”的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支,比如2-3-stable2-4-stable等等。

以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号。

总结:

对于三大工作流,我个人认为没有绝对的最好和最坏的合作方式.

在不同场景下,不同工作流各自有着各自的优势,根据团队情况,项目情况选择合适的工作流是最重要的。

同时可以根据实际对工作流进行修改,不必生搬硬套。

希望你有所收获~

Default image
LIU
代码是躯体,思想是灵魂

Leave a Reply