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
合并分支
- 开发完成后,封版,先把各个成员的分支合并到对应版本的release
- 封版后要发版本到生产环境,把release合并到main
hotfix 分支
- 分支命名: hotfix/ 开头的为修复分支,它的命名规则与 release 分支类似
- 线上出现紧急问题时,需要及时修复,以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两大分支