We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
说明:以下是前期公司内部试行的简单的代码分支版本流程管理规范,规范其实和运维有很大的关联,随着管理方式和流程的完善,代码版本管理流程也是会改变的。仅供参考!!!
dev-xxx
xxx
年月日
dev-20180612
dev-xx需求
test
test-xxx
master
uat
prod
prod-xxx
图解:
fork
PR
prod-xxxx
(一个完整流程到此结束)
当有新需求开发时,一般是经过需求评审后,定下的冲刺迭代版本,评估了开发周期,确认了上线时间。
dev-xxxx
bug-prod-xxx
merge
Jenkins
(一)冲突的新需求情景:
2018-06-09 CRM 前端上线了,上线后开发人员备份了生产分支代码为 prod-20180609,第二天,前端开发人员紧接着开发新需求,并且新需求有两个版本,版本一 是在下周上线;版本二 是在月底上上线。版本一和版本二是不同的开发人员,启动开发时间是一样的。这时候,开发人员应该基于 master 分支创建出两个分支,假设为 dev-20180618-需求1 和 dev-20180625-需求2,然后他们都是各自在各自分支里边开发,相互不影响。
2018-06-09
prod-20180609
dev-20180618-需求1
dev-20180625-需求2
(二)线上 BUG 情景:
问题来了:上线后第三天,线上用户反馈了 bug,需要紧急修复。
做法:基于远程仓库主分支的版本标签 prod-20180609 创建新分支bug-prod-xxx,在此新分支修改 bug,自测没问题后 PR 到主仓库 test(如果该分支已经被新需求占用,可以创建新分支test-bug,Jenkins 构建选对就好),jenkins构建后 QA 测试,没问题后,将 test 分支 merge到 master 分支,没问题后再覆盖更新到 prod上线,上线完成后,备份新生产分支,打标签prod-xxxx。
test-bug
jenkins
(三)公共代码(非需求代码变动)情景:
修改公共代码的同学,需要自己创建一个专门用来改公共代码的分支出来。公共代码或者是公共类库和基础服务等代码改动了,也要和业务代码一样,提测走完测试流程。
本文属于《前端团队工程化记录》 的一小节内容,更多请前往了解。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
分支说明
dev-xxx
为开发分支,xxx
表示版本,建议使用上线年月日
时间串,比如dev-20180612
或 为需求功能点名称,比如dev-xx需求
test
为测试分支 (如果存在多版本同时测试,可能存在test-xxx
分支,意思是多个测试环境,有做压测或者是功能测试的)master
主分支为uat
回归测试分支(预生产/准生产分支)。(此分支会做分支保护,不允许直接 push 和 只有主程序员可以 merge )prod
为生产发布分支prod-xxx
为生产上线后备份tag分支版本流程管理
图解:
prod
分支创建新开发分支dev-xxx
;fork
主仓库到自己名下,(如果原来已经 fork 过,可以通过更新的方式更新获取到最新的master
和dev-xxx
代码),切换到分支dev-xxx
进行开发;fork
仓库,适当时机PR
merge 到 远程项目主仓库对应的dev-xxx
分支;dev-xxx
分支代码合并提交到test
分支;(建议是fork
仓库的分支dev-xxx
提交到了远程主仓库的dev-xxx
分支,再用主仓库的远程dev-xxx
分支合并到test
分支)test
分支代码通过后,就将test
分支 PR 合并到master
分支,进行回归测试;uat
测试有 bug,重复(3)(4)(6)步骤;如果uat
测试失败,运维要回滚uat
环境和生产一致。uat
测试通过,产品验收通过,则将代码覆盖更新到prod
分支,进行上线安排,上线出问题还是要有紧急回滚机制。prod
分支版本打标签,如prod-xxxx
(xxx 为上线日期)(一个完整流程到此结束)
情景举例说明
迭代新版本
prod-xxxx
创建一个分支出来,比如取名为dev-xxxx
,然后基于此分支开发同版本的需求上线,要提交 Jenkins 构建的话就 merge 到对应的测试分支。PR
到test
分支,QA 完成功能测试没问题后,将test
分支 merge 到master
分支进行回归测试。生产上有 bug,需紧急修复上线
prod-xxx
创建分支修改 bug,分支名称为bug-prod-xxx
,改完自验没问题需要提交测试的时候,merge
到相应测试分支(如test
),Jenkins
构建后验证通过,上线生产。上线完成后,别忘记了备份新生产分支prod-xxxx
。然后其他正常使用的分支,需要拉取最新生产分支代码prod-xxxx
,保证拥有最新的生产分支代码,避免 bug 又上线了(这个过程在以上把 master 定为准生产分支时规避掉了)。故事举例:
(一)冲突的新需求情景:
2018-06-09
CRM 前端上线了,上线后开发人员备份了生产分支代码为prod-20180609
,第二天,前端开发人员紧接着开发新需求,并且新需求有两个版本,版本一 是在下周上线;版本二 是在月底上上线。版本一和版本二是不同的开发人员,启动开发时间是一样的。这时候,开发人员应该基于master
分支创建出两个分支,假设为dev-20180618-需求1
和dev-20180625-需求2
,然后他们都是各自在各自分支里边开发,相互不影响。master
,合并最新生产代码(因为可能会有遗漏,有人改过没更新同步你们的分支),然后再PR
到test
分支测试。(二)线上 BUG 情景:
问题来了:上线后第三天,线上用户反馈了 bug,需要紧急修复。
做法:基于远程仓库主分支的版本标签
prod-20180609
创建新分支bug-prod-xxx
,在此新分支修改 bug,自测没问题后PR
到主仓库test
(如果该分支已经被新需求占用,可以创建新分支test-bug
,Jenkins 构建选对就好),jenkins
构建后 QA 测试,没问题后,将test
分支merge
到master
分支,没问题后再覆盖更新到prod
上线,上线完成后,备份新生产分支,打标签prod-xxxx
。(三)公共代码(非需求代码变动)情景:
修改公共代码的同学,需要自己创建一个专门用来改公共代码的分支出来。公共代码或者是公共类库和基础服务等代码改动了,也要和业务代码一样,提测走完测试流程。
总结
本文属于《前端团队工程化记录》 的一小节内容,更多请前往了解。
The text was updated successfully, but these errors were encountered: