git规范

分支

main 主分支

  • main 为主分支,也是用于部署生产环境的分支,确保main分支稳定性
  • main 分支一般由develop以及hotfix分支合并,任何时间都不能直接修改代码

release 版本分支

  • 开发新版本时,以main为基础创建release分支
  • 分支命名: release/ 开头的为版本分支, 命名规则: release/v1.0.0
//1.切换到main
git checkout main 
//2. 拉取main最新代码
git pull
// 3. 基于main创建并切换到release分支
git checkout -b release/v1.0.0 //开发1.0.0版本

版本号

v1.0.0
软件版本号由三部分组成
  • 第一个为主版本号
  • 第二个为子版本号
  • 第三个为阶段版本号
版本号定修改规则
  • 主版本号:当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
  • 子版本号:当功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
  • 阶段版本号:一般是 Bug 修复或是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版。此版本号由项目经理或负责人决定是否修改。

多人开发release版本分支

创建分支

从在release分支的基础上创建新分支

//例如现在要开发v1.0.0的需求
//1.切换到release/v1.0.0的分支
git checkout release/v1.0.0
//2. 拉取最新代码
git pull
//3.创建并切换到release/v1.0.0分支下pyj成员的分支
git checkout -b release/v1.0.0_${成员} //如: git checkout -b release/v1.0.0_pyj

合并分支

  1. 开发完成后,封版,先把各个成员的分支合并到对应版本的release
  2. 封版后要发版本到生产环境,把release合并到main

hotfix 分支

  1. 分支命名: hotfix/ 开头的为修复分支,它的命名规则与 release 分支类似
  2. 线上出现紧急问题时,需要及时修复,以main分支为基线,创建hotfix分支,修复完成后,需要合并到main分支
//hotfix修复一般为紧急功能模块bug,避免冲突所以加上日期
git checkout -b hotfix/${日期}_${模块} //如: git checkout -b hotfit/2023.05.12_user

提交

规范

  • feat: 添加新特性
  • fix: 修复bug
  • docs: 仅仅修改了文档
  • style: 仅仅修改了空格、格式缩进、都好等等,不改变代码逻辑
  • refactor: 代码重构,没有加新功能或者修复bug
  • perf: 增加代码进行性能测试
  • test: 增加测试用例
  • chore: 改变构建流程、或者增加依赖库、工具等
feat: 完成xxx功能
fix: 修改xxx报错

建议

  • 提交要分类,例如同时开发功能和修改bug,则可以分成2次提交,一次feat一次fix
  • 提交的代码尽量少,例如开发一个列表页面,有筛选栏,有table,有弹窗,则可以分成三次提交,如 feat: 完成xxx页筛选栏, feat: 完成xxx页table, feat: 完成xxx页弹窗

其它

主分支为什么不叫master

市场上master和main都有,我们公司创建项目默认分支是main,所以使用main

为什么无develop和feature

develop(开发主分支)和feature(功能)分支,在大型项目有使用,我们项目相对而言不是很庞大,并且大多的分支容易混淆,跟着需求的版本走就够用了,所以分main和release两大分支

作者:aaaa原文地址:https://segmentfault.com/a/1190000043779900

%s 个评论

要回复文章请先登录注册