AgileBPM 代码持续升级说明

本章节介绍了 AgileBPM 的 Git 协作流程,以及如何持续的 更新 AgileBPM 的代码

商业用户 代码版本升级步骤

一般代码维护升级步骤如下:

  1. 将源码上传到公司的Git私服上,上传后默认为保护分支 master
  2. 在 master 分支上创建 两个分支:开发分支 “develop” 、升级专用分支“upgrade”
  3. 当以后获取到 AgileBPM 新版本源码后,将源码覆盖推送到 “upgrade” 分支上
  4. 然后将升级后的 “upgrade” 分支合并到 “develop” 开发分支之上(如果存在冲突需要根据情况解决)
  5. 最后在开发分支 “develop” 验证后,走版本发布流程最终合并到 master 主干完成版本升级

总体思路就是专门用一个分支维护版本的升级,升级后合并到自己开发分支即可。

建议:将基础模块源码 deploy 到私服上,不需要所有人关注所有模块源码,大多人只需要引入依赖即可。

AgileBPM Git 开发协作流程

AgileBPM 的开发员 需要严格按照该协作流程

master
稳定分支,存储了正式发布后的源码
develop
正常版本迭代功能开发的分支,分支命名:*-SNAPSHOT
release
当develop 完成了当前版本规划的内容的时候,我们需要创建一个发布分支,分支命名: *-Beta

从这个时间点开始之后,新的功能不能再加到这个分支上 —— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。
一旦对外发布的工作都完成了,发布分支合并到master分支并分配一个版本号打好Tag。
另外,这些从新建发布分支以来的做的修改要合并回develop分支
Hotfix
为Bug修复使用专门分支,分支命名:*-BUGFIX

这是唯一可以直接从master分支fork出来的分支。修复完成,修改应该马上合并回master分支和develop分支
Master分支使用新的版本号打好Tag
Feature
新特性 或者探索功能,单独拉分支开发,分支命名:*-xxx  (具体代号,如*-flowable。标识flowable尝试整合版本)

源码下载

请务必 Fork 项目到自己账户下,用 git下载到本地,使用 git 来管理代码,建议Star持续关注动态
项目地址 https://gitee.com/agile-bpm/agile-bpm-basic

缺陷、功能贡献

请使用 pull request 功能 参与贡献

带提交记录的代码版本升级

如果非 fork 形式 下载的源码,建议从初始化版本拉一个分支,然后下载 AgileBPM 新版本 全覆盖更新 该初始化分支,最后合并至主干即可。

如果 fork了AgileBPM 源码那么可以远程的形式 去合并,步骤如下:

  1. Team > Remote > Fetch from…
  1. Custom URI 设置 Location URI 为: https://gitee.com/agile-bpm/agile-bpm-basic.git 然后点击 Next
  1. 设置 Source ref、 Destination ref,点击 add ,最后点击 finish
  1. 使用 Team Rebase 功能,选择一个 fetch 来的分支进行合并 ( Rebase / Merge )
  1. Rebase
    简单看下更新相关文件,点击 proceed

接着解决冲突、最后提交即可
可以点击 Rebase 下的 Abort 可以取消合并
如图: