前言

在讨论规范之前，我们需要定最基本的要求

1.团队内保持良好的代码格式便于易读和维护，最主要减少不必要的代码冲突（建议统一使用开发工具（idea）的代码格式化）
2.提交任何代码必须确认代码可运行
3.提交的代码必须移除无用的包路径引用和无用的依赖，尽量不要使用过期的方法或者类

---

---

一、commit message规范

规范格式: <type>: <subject>

type
feature: 新功能（feature）
fix: 修补bug、style等
refactor: 重构（即不是新增功能，也不是修改bug的代码变动）
test: 增加测试 chore: 构建过程或辅助工具的变动

subject
提交目的的简短描述，描述做了啥或者改了啥，如果有团队管理工具(issue ,JIRA)或者产品需求，必须以内部命名的需求代号作为描述信息的一部分，方便查看日志，合并和cherry-pick。

举例：

• feature:开发完成#代号 XXX.XXX需求
• fix:修改 #代号 XXXX查询问题

---

---

二、GIT开发流程

Git分支

• master （生产环境） 部署某个uat功能到准生产的时候合并到master，只允许uat分支合并/cherry-pick。
• uat （测试环境） 部署某个feature分支到测试的时候合并到uat，只允许feature分支合并。
• feature/xxxx (特性分支) 开发一个功能或者修改bug的时候合并/提交到feature
• dev/xx (本地开发版本)

在开发之前，需要在master分支上切一个以需求,BUG,重构.......命名feature分支 ，比如 feature/项目编号（BUG的代号）