Git 开发工作流

开发流程

  1. 本地开发 - 开发前要在 issue 上面添加对应功能点或者修复的问题
  2. 提交分支 - 先提交到 fork 工程
  3. 走 Pull Request 到 develop 分支
  4. 合并 master 分支
  5. 生成 Release 版本
  6. 发布

提交前运行验证脚本

一般情况, 项目应该在初始化时构建可行性验证脚本(单元测试, 集成测试, 关键性检查)

例如: java 项目跑着三个命令确定下, 是否有问题

  • mvn -B clean apache-rat:check findbugs:findbugs (校验文件许可证)
  • mvn -Prelease-nacos clean install -U (编译打包命令)
  • mvn clean install -Pit-test (跑集成测试)

分支规范

基本规范

  1. 前后端源码文件必须要走 pull request, 经多人相互 review 后方可合并.
  2. 所有的 PR 提交合并的分支是 develop, 提交前要先将 develop 合并到自己分支解决冲突。
  3. 所有在 master 上单独修改的点, 都需要在 develop 合并。

讨论点:是否要作为 master 作为主分支的展现。

主要分支流程

分支名称(规则) 含义
master 主分支
develop 开发分支
feature_功能点 功能开发分支
hotfix_修复点 bug修复分支
版本号 主线版本release的开发分支

功能性hotfix分支, 在开发完毕合并 develop 后没有问题, 就可以销毁.
还可以 fork 项目中自己直接提交 PR 合并到 develop 上.

Release 规范

Release 流程

  1. 开发分支[develop]校验是否都提交完成了所有修改点
  2. 开发分支已经跑通了 travis-ci
  3. 进行提交 pull request 合并 master 分支。把变更里边的信息全部合并提交记录里边
  4. 检查记录没有问题进行发布版本

需要 check 的点

规范请参照以往的版本

  1. 对应每一个变更点的 issues 关联
  2. 版本命名规范, 三位数字版本, RC 作为 ready 版本结尾
  3. 保证每个过程的 travis-ci 通过
Donate - Support to make this site better.
捐助 - 支持我让我做得更好.