网站建设的一般过程,新密做网站推广,虎嗅 wordpress,一级a做爰片免费网站冫Git是目前最流行的代码管理工具#xff0c;相信大家也都是在用Git来管理自己团队的源代码。
团队一般为了规范开发#xff0c;保持良好的代码提交记录以及维护 Git 分支结构清晰#xff0c;方便后续维护等#xff0c;都会迫切需要一个比较规范的 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: 构造工具的或者外部依赖的改动例如webpacknpm
refactor: 代码重构时使用
revert: 执行git revert打印的message# 暂不使用type
test: 添加测试或者修改现有测试
perf: 提高性能的改动
ci: 与CI持续集成服务有关的改动
chore: 不修改src或者test的其余修改例如构建过程或辅助工具的变动Commit messages格式要求
# 标题行50个字符以内描述主要变更内容
#
# 主体内容更详细的说明文本建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug增加一个feature提升性能、可靠性、稳定性等等
# * 如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 如果需要的话可以添加一个链接到issue地址或者其它文档示例
# fix修复支付宝支付bug
#
# 1修复支付完成后未查询支付状态问题
# 2增加定时任务保证支付状态完整
#
# linkhttp://github.com/ftd/shopmall/issue001注如果一次改动内容较多包含多个提交类型时建议拆分成多个提交分次提交这样会更清晰。 Git Flow工作流
我们现在已经了解了Git的分支包括分支有哪些类型什么情况下使用什么类型的分支以及提交的格式规范等。不过往往在一个团队人数较多创建的分支也比较多的时候还是会带来很多分支操作上的困扰。那有没有一个什么好的流程来规范大家呢针对这些问题建议大家使用Git Flow的工作流模式。
Git Flow 流程图
1主分支流程
master分支记录了每次版本发布历史和tag标记。develop分支记录了所有开发的版本历史。develop分支仅第一次创建时从master分支拉取。
2开发流程
feature分支是从develop分支拉取的分支。每个feature完成后需合并到develop分支。
3提测发布流程
release分支是在所有功能开发自测完成后从develop分支拉取的分支。release分支一旦创建后通常不再从develop分支拉取该分支只做bug修复文档生成和其他面向发布的任务。release分支测试完成达到上线标准后需合并回master分支和develop分支。
4bug修复流程
hotfix分支是在线上出现bug之后从master分支拉取的分支。hotfix分支测试完成后需合并回master分支和develop分支。
Git Flow实战
Git Flow的流程搞清楚后我们下面开始实际的项目实战假设我们现在有一个商城的项目并且我们已经建好了Git仓库。
我们通过命令行和图形界面的方式分别向大家展示如何使用Git Flow工作流。
Git Flow 命令示例
开始 Feature
# 创建feature分支
git flow feature start ftd_20201018_wechatpay# 指定当前分支pull的源为develop
git branch --set-upstream-toorigin/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大家可以看到简简单单几行命令就可以完成比较复杂的流程管理如果对于命令行不太擅长的小伙伴还可以使用图形工具这里推荐使用sourcetreesourcetree也是著名的Git管理工具可以大大方便我们对Git的操作和使用下面就来介绍一下sourcetree中如何使用Git Flow。 注以下内容为Windows版本的sourcetree为例Mac类似。 初始化GitFlow
打开sourcetree选择想使用Git Flow工作流的项目在右上角点击Git工作流按钮如下图所示
随后会弹出对话框可以选择产品分支开发分支以及功能分支等如下图所示
点击确定后完成仓库的Git Flow初始化。
开始 Feature
点击右上角Git工作流显示如图界面
输入本次功能的名称点击确定创建feature分支
可以看到本地已经有了新建的feature分支如图所示
然后就可以在该分支进行功能开发了。
完成 Feature
功能开发完成之后还是点击右上角Git工作流显示如图界面
点击完成功能如下图所示
这里可以选择将该feature分支删除或保留可以根据团队的规定来处理即可。
点击确定后完成feature功能的开发。
至此该流程处理完毕。
开始 Release
同样的点击右上角Git工作流选择建立新的发布版本显示如下
输入发布版本名称点击确定完成release分支的创建。
此时可以看到已经创建的release分支如下图所示
完成 Release
测试通过后可以进行release版本的发布如下图所示
输入该发布的标签信息点击确定进行发布。
至此我们已经完成了release的发布流程。
Hotfix
hotfix流程与上述流程操作方法类似再次不再赘述大家可以通过软件进行操作练习。
结语
好了到这里我们关于Git工作流的内容已经全部讲完啦大家可以根据自己团队的需要进行使用和改进以让团队的协作更加高效和规范。
如果你喜欢本文,
扫描二维码关注「我是开发者FTD」公众号 关注开发更关注开发者
