Git规范

团队开发中，遵循一个合理、清晰的 Git 规范，是非常重要的。

否则，每个人都提交一堆杂乱无章的 commit 和分支，项目很快就会变得难以协调和维护。

分支规范

master：主分支。

主分支，始终与正式环境代码保持一致。
不能将代码直接 commit 到该分支，仅合并 develop 在测试服验证完成的代码。

develop：开发分支。

开发分支，在测试环境验证过的分支请求合并到该分支。
不能将代码直接 commit 到该分支，合并 feature、fixbug 分支的代码。

develop-cicd：开发分支，与测试服代码保持一致。
feature：功能开发分支。

开发功能分支，当有新功能需要开发时，则从 develop 拉新 feature 出来。

fixbug：bug 修复分支。

新需求

来新需求了，从哪里开新分支？

直接从 develop 拉新 feature 分支即可。

新需求来了，开新分支

需求完成

需求完成了，合并到哪个分支？

请求合并到 develop-cicd 分支即可，然后到测试环境验证。

需求完成了，请求合并发布到测试服

测试服解决bug

测试环境中出现 bug 了，在哪个分支修复？

直接在对应的 feature 分支进行修改后再请求合并到 develop-cicd 进行测试。

测试服测出bug了，进行解决再更新

更新正式服

测试完成，请求合并到哪个分支进行发布？

测试环境验证完成后再请求合并到 develop 分支。

从 develop 分支请求合并到 master 分支。

测试完成了，请求合并发布到正式服

正式服解决bug

测试环境没测试出来，正式环境出现 bug 了，在哪个分支进行修复？

直接从 develop 拉新 fixbug 分支进行解决，然后请求合并到 develop-cicd 进行测试。

测试环境验证完成后再请求合并到 develop 分支。

正式服出bug了，进行解决和测试再更新正式服

Commit message 规范

格式化的 Commit message，有几个好处。

提供更多的历史信息，方便快速浏览。
可以过滤某些 commit（比如文档改动、依赖升级等），便于快速查找信息。
可以直接从 commit 生成 Change log。

提交规则：不允许大量代码一起提交，所提交的内容必须是在 commit message 描述中有体现。

前缀

feature：新功能，新业务。
fixbug：修补 bug。
docs：文档。
refactor：重构（即不是新增功能，也不是修改 bug 的代码变动）。
test：增加测试。
style：格式（不影响代码运行的变动）。
up：依赖升级。

举例

feature：用户模块实体、mapper、service。
feature：用户模块接口。
feature：member表新增字段。
fixbug：修改用户信息名称字段使用错误。
docs：开发规范类注释模板修改。
refactor：用户实体名称修改。
test：增加修改用户名称测试。
style：代码格式化。
up：Spring依赖升级，从2.x到3.x。

日常bb