开发流程
- 本地开发 - 开发前要在 issue 上面添加对应功能点或者修复的问题
- 提交分支 - 先提交到 fork 工程
- 走 Pull Request 到 develop 分支
- 合并 master 分支
- 生成 Release 版本
- 发布
提交前运行验证脚本
一般情况, 项目应该在初始化时构建可行性验证脚本(单元测试, 集成测试, 关键性检查)
例如: java 项目跑着三个命令确定下, 是否有问题
- mvn -B clean apache-rat:check findbugs:findbugs （校验文件许可证）
- mvn -Prelease-nacos clean install -U （编译打包命令）
- mvn clean install -Pit-test （跑集成测试）
分支规范
基本规范
- 前后端源码文件必须要走 pull request, 经多人相互 review 后方可合并.
- 所有的 PR 提交合并的分支是 develop, 提交前要先将 develop 合并到自己分支解决冲突。
- 所有在 master 上单独修改的点, 都需要在 develop 合并。
讨论点：是否要作为 master 作为主分支的展现。
主要分支流程
| 分支名称（规则） | 含义 |
| master | 主分支 |
| develop | 开发分支 |
| feature_功能点 | 功能开发分支 |
| hotfix_修复点 | bug修复分支 |
| 版本号 | 主线版本release的开发分支 |
功能性 和 hotfix分支, 在开发完毕合并 develop 后没有问题, 就可以销毁.
还可以 fork 项目中自己直接提交 PR 合并到 develop 上.
Release 规范
Release 流程
- 开发分支[develop]校验是否都提交完成了所有修改点
- 开发分支已经跑通了 travis-ci
- 进行提交 pull request 合并 master 分支。把变更里边的信息全部合并提交记录里边
- 检查记录没有问题进行发布版本
需要 check 的点
规范请参照以往的版本
- 对应每一个变更点的 issues 关联
- 版本命名规范, 三位数字版本, RC 作为 ready 版本结尾
- 保证每个过程的 travis-ci 通过
