背景
流程
Owner基于master建立开发分支xxx-dev-v1,xxx-release-v1,分别是第一期开发版本,第一期发布版本。
xxx-dev-v1供开发人员拉取并开发,功能点开发完成且单元测试通过后,将开发代码提交到xxx-dev-v1上。
测试人员测试xxx-dev-v1的代码,测试通过后,由本人将xxx-dev-v1的代码合并到xxx-release-v1,待发布。发布前若测试人员发现bug,则重复3、4步。
发布时,由Owner将xxx-release-v1合并到master分支,合并后master分支打tag,如master> git tag 20171220-v1.0,然后运行自动发布脚本进行发布。
项目是迭代开发,第一期完成后该进行第二期开发,命名方式相同,依次类推。
如果在开发V2的过程中,需要紧急修复V1(线上)中的漏洞,则重复3、4、5步,并在最后将master的代码合并到V2上,以保证V2的代码最新;如评估后不紧急,可放在V2中开发。
注意
务必保证master是线上最新版本。
可改进的地方:经过一段时间的策略使用,认为目前的问题在于角色分工上不够明确,具体表现在两个问题:(1)开发人员代码开发并提交dev分支后,应该提起dev到release的合并请求,由Owner审核后通过,而不是Owner发起合并(2)测试人员在测试没有bug后应提起release合并到master的请求,而不是由Owner发起合并。