AgileBPM 代码持续升级说明

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

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

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

  1. 将源码上传到公司的Git私服上，上传后默认为保护分支 master
  1. 在 master 分支上创建 两个分支：开发分支 “develop” 、升级专用分支“upgrade”
  1. 当获取 AgileBPM 新版本源码后，将源码覆盖推送到 “upgrade” 分支上（建议不引入项目以纯源码文本形式，先删除本地全部源码，然后覆盖新版本）
  1. 将升级后的 “upgrade” 分支合并到 “develop” 开发分支之上（如果存在冲突需要根据情况解决），并根据升级的版本号逐一执行 upgrade SQL 语句
  1. 最后在开发分支 “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 可以取消合并
如图：