外观
AgileBPM 代码持续升级说明
本章节介绍了 AgileBPM 的 Git 协作流程,以及如何持续的 更新 AgileBPM 的代码
商业用户 代码版本升级步骤
一般代码维护升级步骤如下:
将源码上传到公司的Git私服上,上传后默认为保护分支 master
在 master 分支上创建 两个分支:开发分支 “develop” 、升级专用分支“upgrade”
当获取 AgileBPM 新版本源码后,将源码覆盖推送到 “upgrade” 分支上(建议不引入项目以纯源码文本形式,先删除本地全部源码,然后覆盖新版本)
将升级后的 “upgrade” 分支合并到 “develop” 开发分支之上(如果存在冲突需要根据情况解决),并根据升级的版本号逐一执行 upgrade SQL 语句
最后在开发分支 “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 源码那么可以远程的形式 去合并,步骤如下:
- Team > Remote > Fetch from...
Custom URI 设置 Location URI 为: https://gitee.com/agile-bpm/agile-bpm-basic.git 然后点击 Next
设置 Source ref、 Destination ref,点击 add ,最后点击 finish
使用 Team Rebase 功能,选择一个 fetch 来的分支进行合并 ( Rebase / Merge )
- Rebase 简单看下更新相关文件,点击 proceed
接着解决冲突、最后提交即可 可以点击 Rebase 下的 Abort 可以取消合并 如图: