五里店网站建设,网站备案邮寄资料,做网站导航cms,长沙竞价优化目的
俗话说#xff1a;没有规矩#xff0c;不成方圆。遵循一个好的规章制度能让你的工作事半功倍。同时也可以展现出你做事的认真的态度以及你的专业性#xff0c;不会显得杂乱无章#xff0c;管理困难。Git分支规范也是一样。当遵循了某种约定的Git分支#xff0c;在代…目的
俗话说没有规矩不成方圆。遵循一个好的规章制度能让你的工作事半功倍。同时也可以展现出你做事的认真的态度以及你的专业性不会显得杂乱无章管理困难。Git分支规范也是一样。当遵循了某种约定的Git分支在代码提交以及多开发、多分支协同工作的时候必须遵循这个规范操作否则不予以提交、合并代码、提测、上线等操作。
适用范围
适用Git管理开发的所有项目 分支约定
Git Flow有主分支和辅助分支两类分支通常主分支也被称为长期分支。 主分支用于组织与软件开发、部署相关的活动 辅助分支组织为了解决特定的问题而进行的各种活动。
主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。
分支介绍
• tag
使用release发布生产成功后三日之内把release分支合并到master上并打tag。
使用realase分支创建tag版本使用tag进行线上部署
生产流水线自动打tag
• master分支
不接受commit只接受来自realase分支的merge操作
分支必须开启分支保护只有维护者可以操作
• release分支
可从test/master分支上拉取
不接受commit只接受来自对应test分支的合并操作
普通开发人员不具有合并权限需要管理员才能合并
release分支用于发布预生产环境部署
上线成功后必须立即合并到master
release分支用于发布生产环境部署上线完成后禁止合并
• test分支
从master/develop分支拉取用于测试环境部署
不接受commit提交只接受来自对应develop的合并
• develop分支
从master/feature分支拉取用于开发环境部署
不接受commit提交只接受来自feature的合并
• feature分支
不限制从什么分支拉取拉取代码时候版本号必须大于等于最新master的版本
可直接commit
一般不用于任何环境部署特殊情况可以用于开发环境部署
禁止用于测试、预生产、灰度、生产部署
bug修复分支也按feature分支规范和流程
• hotfix分支
紧急bug修复分支仅用于紧急的线上问题修复普通bug修复还是使用feature分支规范 分支命名规则及对应环境 分支 命名规则 名称 环境 权限 master master 主分支保护分支只接受merge - 保护 tag tag-{上线时间}-v{版本号} tag 如tag-20220803-v1.2.0 - 只读 release release-{时间}-{版本号}-{创建人} 预上线分支release-20220803-v1.2.0-liuyy 预生产、生产 保护 test test-{时间}-{功能描述}-{创建人} 除了前缀名称与develop一致 测试部署分支 test-20220803-superChargeV1-liuyy 测试 保护 develop develop-{时间}-{功能描述}-{创建人} 除了前缀名称与feature一致 开发部署分支develop-20220803-superChargeV1-liuyy 开发 常规 feature feature-{创建时间}-{功能描述}-{创建人} 功能开发分支feature-20220803-superChargeV1-liuyy - 常规 hotfix hotfix-{创建时间}-{bug描述}-{创建人} 紧急bug修复分支hotfix-20220803-bugxxx-liuyy 不限 常规
分支规则正则
--javascripttypescriptbashsqljsonhtmlcssccppjavarubypythongorustmarkdown
^(test|feature|develop|hotfix)-(20\d{6})(-\w){2}$|^(release|tag)-(20\d{6})-v\d(\.\d){2}(-\w){0,1}$
分支使用示意图 总结
1、一个上线需求一个feature分支正常情况feature、develop、test、release分支是一一对应的
2、如果有多个需求需要合并上线那么需要从develop分支开始合并即多个feature对一个develop分支但develop、test、release也还是一一对应的
3、除了feature分支外所有分支都不接受commit只接受合并
4、普通bug修复使用feature分支流程一样
5、紧急bug修复走hotfix分支流程
6、所有上线的代码必须走完完整的develop、test、release流程
代码提交规范 所有commit必须有注释内容必须简洁明了的描述本次commit涵盖了哪些内容。严禁注释内容过于简单或不能明确表达提交内容的 合理控制提交内容的颗粒度一次commit含一个独立功能点。严禁一次提交涵盖多个功能项。 提交注释字符数务必大于8, 尽量控制在60个字符之内。
建议参考规范
示例
fix(首页模块)修复弹窗 JS Bug。
type(可选表示动作类型可分为 fix修复 xxx Bug feat新增 xxx 功能 test调试 xxx 功能 style变更 xxx 代码格式或注释 docs变更 xxx 文档 refactor重构 xxx 功能或方法
scope(可选 表示影响范围可分为模块、类库、方法等。
subject(必须) 表示简短描述大于8个字符小于 60 个字如果有编号的 Jira 号建议在描述中加上。
