一文读懂Git工作流

Git是目前最流行的代码管理工具,相信大家也都是在用Git来管理自己团队的源代码。

团队一般为了规范开发,保持良好的代码提交记录以及维护 Git 分支结构清晰,方便后续维护等,都会迫切需要一个比较规范的 Git 工作流。

本文就是在这个背景下诞生的,如果你的团队正好有此需求,那你可以看一下,希望本文能给大家提供一些帮助,建立良好的团队代码流程规范。

本文的目录如下

  • Git主要优点
  • Git分支管理
  • Git日志规范
  • Git Flow工作流
  • Git Flow实战

Git主要优点

  • 分布式存储,本地仓库包含了远程仓库的所有内容。
  • 安全性高,远程仓库文件丢失了也不怕。
  • 优秀的分支模型,创建/合并分支都非常快速便捷。

Git分支管理

我们在实际工作中会创建很多分支以便于不同场景下的开发,但是如果没有分支规范就会造成分支杂乱,大家往往也搞不清楚某一个分支是在做什么,下面我们就介绍一下我们常用的并且推荐大家使用的分支类型。

Git分支类型

master 分支

  • master 为产品主分支,该分支为只读唯一分支,也是用于部署生产环境的分支,需确保master分支的稳定性。
  • master 分支一般由release分支或hotfix分支合并,任何情况下都不应该直接修改master分支代码。
  • 产品的功能全部实现后,最终在master分支对外发布,另外所有在master分支的推送应该打标签(tag)做记录,方便追溯。
  • master 分支不可删除。
develop 分支
  • develop 为主开发分支,基于master分支创建,始终保持最新完成功能的代码以及bug修复后的代码。
  • develop 分支为只读唯一分支,只能从其他分支合并,不可以直接在该分支做功能开发或bug修复。
  • 一般开发新功能时,feature分支都是基于develop分支下创建的。
  • develop 分支包含所有要发布到下一个release的代码。
  • feature功能分支完成后, 开发人员需合并到develop分支(不推送远程),需先将develop分支合并到feature,解决完冲突后再合并到develop分支。
  • 当所有新功能开发完成后,开发人员并自测完成后,此时从develop拉取release分支,进行提测。
  • release或hotfix 分支上线完成后, 开发人员需合并到develop分支并推送远程。
  • develop 分支不可删。
feature 分支
  • feature 分支通常为新功能或新特性开发分支,以develop分支为基础创建feature分支。
  • 分支命名: feature/ 开头的为新特性或新功能分支,建议的命名规则: feature/user_createtime_feature,例如:feature/ftd_20201018_alipay,含义为:开发人员ftd在2020年10月18日时创建了一个支付宝支付的功能分支。
  • 新特性或新功能开发完成后,开发人员需合到develop分支。
  • feature 分支可同时存在多个,用于团队中多个功能同时开发。
  • feature 分支属于临时分支,功能完成后可选删除。
release 分支
  • release 分支为预上线分支,基于本次上线所有的feature分支合并到develop分支之后,从develop分支创建。
  • 分支命名: release/ 开头的为预上线分支,建议的命名规则: release/version_publishtime,例如:release/v2.1.1_20201018,含义为:版本号v2.1.1计划于2020年10月18日时发布。
  • release 分支主要用于提交给测试人员进行功能测试。发布提测阶段,会以release分支代码为基准进行提测。测试过程中发现的bug在本分支进行修复,上线完成后需合并到develop/master分支并推送远程。
  • release 分支属于临时分支,产品上线后可选删除。
当有一组feature开发完成后,首先开发人员会各自将最新功能代码合并到develop分支。进入提测阶段时,开发组长在develop分支上创建release分支。
如果在测试过程中发现bug需要修复,则直接由开发者在release分支修复并提交。当测试完成后,开发组长将release分支合并到master和develop分支,此时master为最新可发布代码,用作产品发布上线。
hotfix 分支
  • hotfix 分支为线上bug修复分支或叫补丁分支,主要用于对线上的版本进行bug修复。
  • 分支命名: hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似,建议的命名规则: hotfix/user_createtime_hotfix,例如:hotfix/ftd_20201018_alipaybugfix,含义为:开发人员ftd在2020年10月18日时创建了一个支付宝支付bug修复的分支。
  • hotfix 分支用于线上出现紧急问题时,需要及时修复,以master分支为基线,创建hotfix分支。当问题修复完成后,需要合并到master分支和develop分支并推送远程。
  • 所有hotfix分支的修改会进入到下一个release。
  • hotfix 分支属于临时分支,bug修复上线后可选删除。

以上就是在工作中常用到的6种分支类型,覆盖了开发中的常见场景,大家也可以根据实际工作情况进行调整,重点是让团队小伙伴都能对整个分支的类型及作用了解即可。

分支创建好了,小伙伴们也都开始按照流程开始开发了,但是在日常开发中由于缺少对于commit message的约束,导致填写内容随意、质量参差不齐,可读性低亦难以维护。在项目中引入commit message规范已是迫在眉睫。书写良好的commit message能大大提高代码维护的效率。

Git日志规范

在一个团队协作的项目中,开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘,最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们,它也反映了一个开发人员是否是良好的协作者。

编写良好的Commit messages可以达到3个重要的目的:

  • 加快代码view的流程
  • 帮助开发人员编写良好的版本发布日志
  • 让之后的维护者了解代码里出现特定变化和feature被添加的原因

目前,社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法,比较合理和系统化。建议使用如下:

Commit messages的基本语法

具体格式为:

# EN
(): 



# CN <类型>[可选的作用域]: <描述> [可选的正文] [可选的脚注]
  • type: 本次 commit 的类型,诸如 bugfix、docs、style 等,类型说明参见下方。
  • scope: 本次 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。
  • subject: 简明扼要的阐述下本次 commit 的主旨,是 commit 目的的简短描述,建议不超过50个字符。
  • body: 在主体内容中我们需要把本次 commit 详细的描述一下,比如此次变更的动机,详细的修改方法或其他需要额外重点说明的内容。
  • footer: 描述下与之关联的 issue 或 break change,详见案例。
Type的类别说明:
# 主要type
feat: 增加新功能
fix: 修复bug
 
# 特殊type
docs: 只改动了文档相关的内容
style: 不影响代码含义的改动,例如去掉空格、改变缩进、增删分号
build: 构造工具的或者外部依赖的改动,例如webpack,npm
refactor: 代码重构时使用
revert: 执行git revert打印的message
 
# 暂不使用type
test: 添加测试或者修改现有测试
perf: 提高性能的改动
ci: 与CI(持续集成服务)有关的改动
chore: 不修改src或者test的其余修改,例如构建过程或辅助工具的变动
Commit messages格式要求
# 标题行:50个字符以内,描述主要变更内容
#
# 主体内容:更详细的说明文本,建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug,增加一个feature,提升性能、可靠性、稳定性等等
# * 如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险? 
#
# 如果需要的话可以添加一个链接到issue地址或者其它文档
示例:
# fix:修复支付宝支付bug
#
# 1,修复支付完成后未查询支付状态问题
# 2,增加定时任务保证支付状态完整
#
# link:http://github.com/ftd/shopmall/issue001
注:如果一次改动内容较多,包含多个提交类型时,建议拆分成多个提交,分次提交,这样会更清晰。

Git Flow工作流

我们现在已经了解了Git的分支,包括分支有哪些类型,什么情况下使用什么类型的分支,以及提交的格式规范等。不过往往在一个团队人数较多,创建的分支也比较多的时候,还是会带来很多分支操作上的困扰。那有没有一个什么好的流程来规范大家呢,针对这些问题,建议大家使用Git Flow的工作流模式。

Git Flow 流程图

1,主分支流程

  • master分支记录了每次版本发布历史和tag标记。
  • develop分支记录了所有开发的版本历史。
  • develop分支仅第一次创建时从master分支拉取。

一文读懂Git工作流_第1张图片

2,开发流程

  • feature分支是从develop分支拉取的分支。
  • 每个feature完成后需合并到develop分支。

一文读懂Git工作流_第2张图片

3,提测发布流程

  • release分支是在所有功能开发自测完成后,从develop分支拉取的分支。
  • release分支一旦创建后,通常不再从develop分支拉取,该分支只做bug修复,文档生成和其他面向发布的任务。
  • release分支测试完成,达到上线标准后,需合并回master分支和develop分支。

一文读懂Git工作流_第3张图片

4,bug修复流程

  • hotfix分支是在线上出现bug之后,从master分支拉取的分支。
  • hotfix分支测试完成后,需合并回master分支和develop分支。

一文读懂Git工作流_第4张图片

Git Flow实战

Git Flow的流程搞清楚后,我们下面开始实际的项目实战,假设我们现在有一个商城的项目,并且我们已经建好了Git仓库。

我们通过命令行和图形界面的方式分别向大家展示如何使用Git Flow工作流。

Git Flow 命令示例
开始 Feature
# 创建feature分支
git flow feature start ftd_20201018_wechatpay

# 指定当前分支pull的源为develop
git branch --set-upstream-to=origin/develop feature/ftd_20201018_wechatpay
完成 Feature
# 发布feature
git flow feature publish ftd_20201018_wechatpay

# 完成feature
git flow feature finish ftd_20201018_wechatpay
开始 Release
git flow release start v1.0_20201031
完成 Release
git flow release finish v1.0_20201031
开始 Hotfix
git flow hotfix start ftd_20201031_bugfix
完成 Hotfix
git flow hotfix finish ftd_20201031_bugfix

大家可以看到,简简单单几行命令就可以完成比较复杂的流程管理,如果对于命令行不太擅长的小伙伴还可以使用图形工具,这里推荐使用sourcetree,sourcetree也是著名的Git管理工具,可以大大方便我们对Git的操作和使用,下面就来介绍一下sourcetree中如何使用Git Flow。

注:以下内容为Windows版本的sourcetree为例,Mac类似。
初始化GitFlow

打开sourcetree,选择想使用Git Flow工作流的项目,在右上角点击Git工作流按钮,如下图所示:

随后会弹出对话框,可以选择产品分支,开发分支以及功能分支等,如下图所示:
一文读懂Git工作流_第5张图片

点击确定后完成仓库的Git Flow初始化。

开始 Feature

点击右上角Git工作流,显示如图界面:
一文读懂Git工作流_第6张图片

输入本次功能的名称,点击确定创建feature分支
一文读懂Git工作流_第7张图片

可以看到本地已经有了新建的feature分支,如图所示:
一文读懂Git工作流_第8张图片

然后就可以在该分支进行功能开发了。

完成 Feature

功能开发完成之后,还是点击右上角Git工作流,显示如图界面:
一文读懂Git工作流_第9张图片

点击完成功能,如下图所示:
一文读懂Git工作流_第10张图片

这里可以选择将该feature分支删除或保留,可以根据团队的规定来处理即可。

点击确定后,完成feature功能的开发。

至此该流程处理完毕。

开始 Release

同样的,点击右上角Git工作流,选择建立新的发布版本,显示如下:
一文读懂Git工作流_第11张图片

输入发布版本名称,点击确定,完成release分支的创建。

此时可以看到已经创建的release分支,如下图所示:
一文读懂Git工作流_第12张图片

完成 Release

测试通过后,可以进行release版本的发布,如下图所示:
一文读懂Git工作流_第13张图片

输入该发布的标签信息,点击确定进行发布。

至此,我们已经完成了release的发布流程。

Hotfix

hotfix流程与上述流程操作方法类似,再次不再赘述,大家可以通过软件进行操作练习。

结语

好了,到这里,我们关于Git工作流的内容已经全部讲完啦,大家可以根据自己团队的需要进行使用和改进,以让团队的协作更加高效和规范。

如果你喜欢本文,

请长按二维码,关注「我是开发者FTD」公众号
一文读懂Git工作流_第14张图片
关注开发,更关注开发者!

你可能感兴趣的:(git)