点击查看【bilibili】
俗话说，没有规矩不成方圆，我们的git也需要规范。

下面介绍一下企业常用的一些规范。

分支管理规范

分支命名不能千奇百怪，必须有统一的命名方式。主要有以下几种：

分支管理 命名规范 解释
master 主分支 master 稳定版本分支，上线完成回归后后，由项目技术负责人从 release 分支合并进来，并打 tag
test 测试分支 test/yyyyMMdd_ 功能名称
示例：test/20220426_blog		 测试人员使用分支，测试时从 feature 分支合并进来
feature 功能开发分支 feature/yyyyMMdd 功能名称负责人员
示例：feature/20220426_blog_xiumubai		 新功能开发使用分支，基于master建立
fix bug修复分支 fix/yyyyMMdd 功能名称负责人员
示例：fix/20220426_blog_xiumubai		 紧急线上bug修复使用分支，基于master建立
release 上线分支 release/版本号
示例：release/0.1.0		 用于上线的分支，基于 master 建立，必须对要并入的 feature 分支进行 Code review 后，才可并入上线

版本号管理规范

当我们上线的时候，需要给版本号打tag，下面是版本号规范：

  1. 项目上线release分支创建定义：
  3. 第一个数字是主版本。第二个数字是次版本。第三个数字是补丁版本(hotfix 类的更新)。
  5. 主版本：含有破坏性更新、大调整等。 例如：1.1.0 > 2.0.0
  7. 次版本：增加新功能特性。例如：1.1.0 > 1.2.0
  9. 补丁版本：修复问题等。例如：1.1.0 > 1.1.1

image.png

提交信息规范

最后是commit的时候，需要对commit信息规范，必须要加前缀

前缀 解释
feat 新功能
fix 修复
docs 文档变更
style 代码格式
refactor 重构
perf 性能优化
test 增加测试
revert 回退
build 打包
chore 构建过程或辅助工具的变动

下图是vue3源码的提交信息规范
image.png
下一节我们就实际操作一下