文章
提交规范
统一开发团队commit 记录，形成统一、具有规范的提交日志，便于开发人员进行代码追溯与review。
格式
<type>[(<scope>)]: <subject> <BLANK LINE> // 空行 [<body>]
- type： 提交类型
- scope：本次提交影响的范围（某个微服务、某个模块、某个结构），对于多模块开发结构可以将某个模块下的具体功能使用 /分割。
- subject： 本次提交的简短描述。
- body： 用于详细描述本次提交的说明。
提交类型
- feat： 新功能（feature）
- fix： 修复 bug
- merge： 合并分支
- docs： 文档注释（ README, CHANGELOG, CONTRIBUTE等）
- style： 代码格式(仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑)
- refactor： 代码重构、优化(既不增加新功能，也不是修复 bug)
- perf： 性能优化
- test： 增加测试
- chore： 改变构建流程、增加依赖库、工具等
- revert： 回滚到到某个版本
- build： 打包构建
提交要求
- 标题行（subject）：50个字符以内，描述主要变更内容
- 主体内容（body）：更详细的说明文本，建议72个字符以内，这部分是可选的，用于补充subject。
分支规范
分支命名
master （main）⭐️
项目的主分支，该分支包含发布到生成环境的最新代码，这个分支由release分支或hotfix分支合并，并且不能直接修改该分支。当要发布新功能时，由release分支合并代码后，此分支需要为此次合并创建一个具有版本号的分支和为该合并点创建tag。
develop（dev）⭐️
开发分支 ，当要新增功能的时候，所有的feature分支都是从这个分支切出去，feature分支的功能开发完成后合并回开发分支。
feature
功能分支，feature分支的由develop分支创建，其分支命名格式为feature/<xxx>，xxx为新功能的名字。
release ⭐️
发布分支，当某一个新功能需要发布，在develop分支上创建一个release分支，在此分支上进行测试与bug修复，之后将release分支合并到develop分支和master分支。
hotfix
补丁分支，当生产环境发现新的bug时候，需要基于master分支创建一个hotfix分支，然后在hotfix分支上修复bug，修复完成后把hotfix分支合并回master和develop分支。
在工作流程建设上，如果需要可以将分支进一步裁减，简化开发流程，裁减feature分支、hotfix分支，功能性开发完全在develop分支上开发，做好提交规范；当生成环境出现bug，直接通过tag或版本分支拉去代码进行bug修复，完成后合回版本分支并创建tag及版本分支。
工作流程
建议
项目依赖于外部二进制程序或其他大型文件构建时，应避免提交git仓库，解决方案：
- Git LFS
- 为某一个或多个文件建立为一个SDK，项目工程依赖于此。
- 通过编程语言特性，将一个或多个文件构建为依赖包，通过包依赖方式依赖这些文件。