协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。"工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。

功能驱动

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

Git flow

特点

git-flow-ow.png

项目存在两个长期分支。

  • 主分支 master
  • 开发分支 develop

前者用于存放对外发布的版本;后者用于日常开发,存放最新的开发版。

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

  • 功能分支 feature branch
  • 补丁分支 hot fix branch
  • 预发分支 release branch

一旦开发完成,它们就会被合并进develop 或 master, 然后被删除

安装 Git flow

windows版本的git 已经自带
其他版本 其他版本安装地址

git-flow 并不是要替代 Git,它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。
严格来讲,你并不需要安装什么特别的东西就可以使用 git-flow
工作流程。你只需要了解,哪些工作流程是由哪些单独的任务所组成的,并且附带上正确的参数,以及在一个正确的顺序下简单执行那些对应的 Git
命令就可以了。当然,如果你使用 git-flow 脚本就会更加方便了,你就不需要把这些命令和顺序都记在脑子里。

使用-初始化

git flow init [-d]

7E0251C3-0A9B-4901-96E1-9A44AAC368B8.png

看起来是不是有点炫,但实际上它只是在你的分支上配置了一些命名规则。建议默认 [-d]

分支模式

  • Master -只能用来包括产品代码。你不能直接工作在这个 master 分支上,而是在其他指定的,独立的特性分支中。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。
  • develop - 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时,它将是_开发_的基础。另外,该分支也汇集所有已经完成的功能,并等待被整合到 master 分支中。

4A6C9C4D-AB21-46E3-8140-2CCC13D77E94.png

这两个分支被称作为长期分支。它们会存活在项目的整个生命周期中。而其他的分支,例如针对功能的分支,针对发行的分支,仅仅只是临时存在的。它们是根据需要来创建的,当它们完成了自己的任务之后就会被删除掉。

功能开发

开始新功能

让我们开始一个新功能 “rss-feed”

E412C074-A4AC-4B5C-8BE5-26F1FB32030D.png

Git flow 会打印出刚刚完成的操作的概述,如果你需要帮助随时可以

git flow feature help

正如上面这个新功能一样,git-flow 会创建一个名为 “feature/rss-feed” 的分支(这个 “feature/” 前缀 是一个可配置的选项设置)。你已经知道了,在你做新功能开发时使用一个独立的分支是版本控制中最重要的规则之一。

git-flow 也会直接签出这个新的分支(即已经自动切换到此新分支),这样你就可以直接进行工作了。

3F8484EE-FB3C-4BE2-BE3F-59991007C87D.png

完成一个功能

经过一段时间艰苦地工作和一系列的聪明提交,我们的新功能终于完成了:

git flow feature finish rest-feed

F3D5E62B-A39C-47B6-850E-F043DEEE51A3.png

最重要的是,这个 “feature finish” 命令会把我们的工作整合到主 “develop” 分支中去。在这里它需要等待:

  • 一个在更广泛的 “开发” 背景下的全面测试。
  • 稍后和所有积攒在 “develop” 分支中的其它功能一起进行发布。
  • 之后,git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支,并且换到 “develop” 分支。

管理 release

Release 管理是版本控制处理中的另外一个非常重要的话题。让我们来看看如何利用 git-flow 创建和发布 release。

创建 release

当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时,这意味着:

  • 第一,它包括所有新的功能和必要的修复;
  • 第二,它已经被彻底的测试过了。
  • 如果上述两点都满足,那就是时候开始生成一个新的 release 了:
Git flow release start 1.1.5

078BAD7C-ED05-4D8E-8104-4A9EF182061D.png

请注意,release 分支是使用版本号命名的。这是一个明智的选择,这个命名方案还有一个很好的附带功能,那就是当我们完成了release 后,git-flow 会适当地_自动_去标记那些 release 提交。
有了一个 release 分支,再完成针对 release 版本号的最后准备工作(如果项目里的某些文件需要记录版本号),并且进行最后的编辑。

完成 release

git flow release finish 1.1.5

需要填写tag  message

5EDFB0A6-75B6-4BA8-870B-12A0BE86AD5D.png
EBC3588A-F271-4454-9EDA-1BDE08D3B6C0.png

这个命令会完成如下一系列的操作:

  • 首先,git-flow 会拉取远程仓库,以确保目前是最新的版本。
  • 然后,release 的内容会被合并到 “master” 和 “develop” 两个分支中去,这样不仅产品代码为最新的版本,而且新的功能分支也将基于最新代码。
  • 为便于识别和做历史参考,release 提交会被标记上这个 release 的名字(在我们的例子里是 “1.1.5”)。
    清理操作,版本分支会被删除,并且回到 “develop”。

从 Git 的角度来看,release 版本现在已经完成。依据你的设置,对 “master” 的提交可能已经触发了你所定义的部署流程,或者你可以通过手动部署,来让你的软件产品进入你的用户手中。

hotfix

很多时候,仅仅在几个小时或几天之后,当对 release 版本作做全面测试时,可能就会发现一些小错误。
在这种情况下,git-flow 提供一个特定的 “hotfix” 工作流程(因为在这里不管使用 “功能” 分支流程,还是 “release” 分支流程都是不恰当的)。

创建Hotfixes

Git flow hot fix start miss-link

这个命令会创建一个名为 “hotfix/missing-link” 的分支。因为这是对产品代码进行修复,所以这个 hotfix 分支是基于 “master” 分支。
这也是和 release 分支最明显的区别,release 分支都是基于 “develop” 分支的。因为你不应该在一个还不完全稳定的开发分支上对产品代码进行地修复。
就像 release 一样,修复这个错误当然也会直接影响到项目的版本号!

完成 Hotfixes

git flow hotfix finish miss-link

这个过程非常类似于发布一个 release 版本:

  • 完成的改动会被合并到 “master” 中,同样也会合并到 “develop” 分支中,这样就可以确保这个错误不会再次出现在下一个 release 中。
  • 这个 hotfix 程序将被标记起来以便于参考。
  • 这个 hotfix 分支将被删除,然后切换到 “develop” 分支上去。

还是和产生 release 的流程一样,现在需要编译和部署你的产品(如果这些操作不是自动被触发的话)。

59240A8C-E3F3-4218-B079-5D8FB9C60D3E.png

回顾总结 ##

首先,git-flow 并不会为 Git 扩展任何新的功能,它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程。

其次,定义一个固定的工作流程会使得团队协作更加简单容易。无论是一个 “版本控制的新手” 还是 “Git 专家”,每一个人都知道如何来正确地完成某个任务。

记住,使用 git-flow 并不是必须的。当积攒了一定的使用经验后,很多团队会不再需要它了。当你能正确地理解工作流程的基本组成部分和目标的之后,你完全可以定义一个属于你自己的工作流程。

Last modification:May 21st, 2021 at 03:36 pm
If you think my article is useful to you, please feel free to appreciate