代码版本分支管理

衍生：

4.3.0-snapshot

tag

4.2.0-snapshot

4.2.0

4.1.1

4.1.0

release/4.2.x

4.1.0-sp1

bugfix/4.2.x

master

release/4.1.x

时间线

hotfix/4.1.0

bugfix/4.1.x

feature

调整依赖版本

bugfix

4.1.0-snapshot

合并：

hotfix

feature-a

优势：# 各开发分支无需被冻结，衍生分支可在任意时刻创建；# 各产品间的release分支可等待被依赖产品发布后再发布，同时，当前产品开发不受影响；# 测试和修复同时进行，以便测试能从中断中快速恢复，也让修复可被快速验证；# master/bugfix依赖最新的修复分支代码，确保修复能够被快速应用到依赖方；# 依赖与被依赖方的开发进度互不影响，无需同步发布新版本；

custom

release

# master分支负责开发计划内的功能，每个阶段开始前，需将次版本号加1；# bugfix分支负责测试和缺陷修复，每当master分支的阶段开发工作结束后，创建与次版本号对应的bugfix分支，版本号始终保持不变。bugfix分支可在任意时间创建，只需记住最后一次变更号即可；# release分支负责版本发布，在bugfix完成一轮测试和修复后便创建该分支，同样，每个次版本号对应一个release分支（必要时可为每个修订版创建release分支）。该分支上仅做（项目和被依赖项目的）版本号调整的变更，不做任何修复提交，后续修订版发布前先合并bugfix上的提交，再更新版本号。修订号从0开始递增。若被依赖项目还未发布release版本，则等待其发布。如果依赖方和被依赖方版本发布周期相差太大，则可考虑为每个修订版创建release分支，确保各版本的发布不受影响；# tag分支负责标记每个发布版本，每当release完成版本号调整后，即标记一个新版本。该分支不进行任何提交；# master、feature、bugfix分支版本号均以SNAPSHOT结尾，以支持持续集成构建。release分支不做持续集成，tag分支仅在有新版本被标记后构建一次并部署相关的演示服务；# 交付给客户的代码应该均来自于tag分支，特殊情况可使用bugfix分支代码；# 各产品间不可超前依赖，master、feature、bugfix应该仅依赖最新的bugfix或tag分支代码，release仅依赖tag分支代码；# 测试与修复均针在bugfix分支上进行；# release引用的被依赖项目的版本号最好是与bugfix依赖的版本号接近，以避免引入未被测试的缺陷；# 版本发布（包括创建release分支或合并bugfix分支、调整版本号、标记版本、发布release公告等）过程可自动化；