版本控制指引.docx
《版本控制指引.docx》由会员分享,可在线阅读,更多相关《版本控制指引.docx(10页珍藏版)》请在优知文库上搜索。
1、版本控制指引概念产品版本项目/子项目所定义的版本,两节:x.y。如智计划1.2,那么这个产品版本号为1.2o工程版本代码构建产物的版本。工程版本号通常为四节,x.yzbuild。x.y继承产品版本号;Z在敏捷项目团队中是冲刺编号,在瀑布团队中为流水号。该节用于区分不同的研发、上线周期;build为构建流水号,通常由构建工具自动生成。测试代码同样也有工程版本号。目前测试代码没有发布流程,也没有通过工具发布,所以z.build由测试团队人员自行决定。原则上每一次正式交付,变更Z。发布标签每一次发布到生产,在git代码库中恪合对应的commit标记一个标签,值为部署物的工程版本,即x.zy.z.bu
2、ildo目标统一分支管理策略以及定义。版本化一切,最终提高项目的团队合作效率、加速新功能开发和发布管理。原则.采用GitHubFlow策略(推荐)或基于主干开发策略。 要求项目有完善的自动化测试、持续集成和部署等相关的基础设施。 版本化一切。.团队有代码审查的相应流程。 具备自动部署的条件规范代码仓库必须:代码应放在集团统一的代码仓库。.必须:工程的可见性不能设置为publico.必须:只允许给项目相关开发人员配置权限,并应该遵循最小授权原则。.必须:代码项目创建在团队空间内,不允许放在个人空间。 建议:团队空间命名格式为:group/subgroupogroup为产品线简称,如果产品线有多个
3、子产品,再加上subgrouposubgroup为子产品简称。如gaia/gfs,group=gaia,subgroup=gfso 建议:代码项目命名格式为:项目代号-模块卜子模块-孙模块。如:gaia-gfs-demozhalo-wechato这样,GIT中完整的空间-项目名为:gaiagfsgaia-gfs-demoo分支命名GitHubFlow 必须:master分支被保护,不允许直接提交至master0 必须:创建分支使用有意义的名称头,功能开发用featureJIRA编号-*zbug修复用bugJIRA编号-*,热修复用hotfixJIRA编号如feature/XM1907901-1
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 版本 控制 指引
