git之版本管理规范

一、git commit

1.commit要求

每一次提交必须是一个完整的功能或者修复完成，不能提交半成品代码。

提交代码时检查清楚，不要把编译文件或者IDE生成的文件提交上去。

反例：.idea、.vscode、target、dist、node_modules等。

 

2.commit message格式

强制要求commit message通过以下格式提交

<type>(<scope>):<subject>

type(必须)用于说明git commit的类别，只允许使用下面的标识。

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动

 

scope(可选)

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

例如在Angular，可以是location，browser，compile，rootScope， ngHref，ngClick，ngView等。如果你的修改影响了不止一个scope，你可以使用*代替。

subject(必须)

subject是commit目的的简短描述，不超过50个字符，禁止出现任何无意义的字词。

 

二、分支管理

1.分支命名

Master/main 分支：

master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性。

master 分支一般由dev以及fix分支合并，任何时间都不能直接修改代码。

dev 分支：

develop 为开发分支，始终保持最新完成以及bug修复后的代码。

一般开发的新功能时，feat分支都是基于dev分支下创建的。

dev分支可以部署到办公室环境。

feat 分支：

开发新功能时，以dev为基础创建feat分支。

分支命名: feature/ 开头的为特性分支， 命名规则: feat/user_module、 feat/cart_module。

feat分支代码只在本地执行，开发完成后合并到dev再部署到环境。

release分支：

release 为预上线分支，发布提测阶段，会release分支代码为基准提测。

release分支代码可以部署到uat环境。

fix 分支：

分支命名: fix/ 开头的为修复分支，它的命名规则与feat分支类似。

线上出现紧急问题时，需要及时修复，以master分支为基线，创建fix分支，修复完成后，需要合并到master分支和dev分支

最终的命名规则可以参考：

master
dev
feat/xxx
release/xxx
fix/xxx

2.Gitlab分支管理

Gitlab中的master分支需要设置为保护分支，不允许随意提交代码，除了项目负责人外，其他人全部设置为developer角色。

负责人进行code review后再通过mr合并分支代码。