1. 首页

带你一文读懂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 <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer> # 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工作流

「2,开发流程」

  • feature分支是从develop分支拉取的分支。

  • 每个feature完成后需合并到develop分支。 带你一文读懂Git工作流

「3,提测发布流程」

  • release分支是在所有功能开发自测完成后,从develop分支拉取的分支。

  • release分支一旦创建后,通常不再从develop分支拉取,该分支只做bug修复,文档生成和其他面向发布的任务。

  • release分支测试完成,达到上线标准后,需合并回master分支和develop分支。 带你一文读懂Git工作流

「4,bug修复流程」

  • hotfix分支是在线上出现bug之后,从master分支拉取的分支。

  • hotfix分支测试完成后,需合并回master分支和develop分支。 带你一文读懂Git工作流

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

Js中文网 – 全球前端挚爱的技术成长平台 www.javascriptC.com
Javascript中文网是以前端进阶资源教程分享为主的专业网站,包括:前端教程、JavaScript资讯、大厂面试题、typescript教程、程序人生、React.js源码解读、Vue3.js技术揭秘等,以帮助开发者成长为愿景的社区

完成 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工作流

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

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

开始 Feature

点击右上角Git工作流,显示如图界面: 带你一文读懂Git工作流

输入本次功能的名称,点击确定创建feature分支 带你一文读懂Git工作流

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

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

完成 Feature

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

点击完成功能,如下图所示: 带你一文读懂Git工作流

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

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

至此该流程处理完毕。

开始 Release

同样的,点击右上角Git工作流,选择建立新的发布版本,显示如下: 带你一文读懂Git工作流

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

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

完成 Release

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

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

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

Hotfix

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

结语

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

作者:我是开发者FTD
链接:https://juejin.im/post/6885504750758920200

看完两件小事

如果你觉得这篇文章对你挺有启发,我想请你帮我两个小忙:

  1. 关注我们的 GitHub 博客,让我们成为长期关系
  2. 把这篇文章分享给你的朋友 / 交流群,让更多的人看到,一起进步,一起成长!
  3. 关注公众号 「画漫画的程序员」,公众号后台回复「资源」 免费领取我精心整理的前端进阶资源教程

JS中文网是中国领先的新一代开发者社区和专业的技术媒体,一个帮助开发者成长的社区,目前已经覆盖和服务了超过 300 万开发者,你每天都可以在这里找到技术世界的头条内容。欢迎热爱技术的你一起加入交流与学习,JS中文网的使命是帮助开发者用代码改变世界

本文著作权归作者所有,如若转载,请注明出处

转载请注明:文章转载自「 Js中文网 · 前端进阶资源教程 」https://www.javascriptc.com

标题:带你一文读懂Git工作流

链接:https://www.javascriptc.com/4683.html

« 2020 Android Studio 4.1 终于发布啦
我在大厂写React,学到了什么?性能优化篇»
Flutter 中文教程资源

相关推荐

QR code