git分支规范

介绍

因为J-ONE上线必须只能从master分支抽取文件，因此我们约定master分支只存放上线文件，不存放源代码。

branch

  • 每个repo有且仅有以下的 branch 和 tag。

Branch: master 、 dev 、 feat 、 release 、 hotfix

其中：

  • master 受保护，不存放源代码，不直接提交代码，所有的 上线文件 需要推送到此分支。

  • dev 受保护，主分支，不能直接提交代码，在这个分支只能增加从 feat 合并 过来的 commit。紧急bug除外，紧急bug处理方式看后文bugfix。

  • feat 分支需要从 dev 切出，然后开发完成后，提交合并请求到 release 分支进行提测。

  • release 分支需要从 dev 切出，用来对项目中各个需求进行合并提测，改 bug 等均在此分支进行，测试成功后，提交合并请求到 dev。

  • hotfix 分支需要 dev 切出，待 bug 修复完成后，提交合并请求到 dev. 即：

master
dev
feat/xxx
release/xxx
hotfix/xxx

Tag

  • 对应每个发布版本的源代码 tag。tag版本号与需求版本一致，从dev分支打tag，命名 release版本号日期，如：release_1.0_20200426

  • 对应每个发布版本的上线文件 tag。tag版本号与需求版本一致，命名 dist版本号日期，如：dist_1.0_20200426

开发流程

  • 从dev分支根据需求，检出分支 feat/xxxx，即 dev --> feat/xxxx

  • 从dev分支检出预发环境测试分支 release/xxxx ，即 dev --> release/xxxx

  • 开发完成后将各个开发分支合并至此，即 feat/xxxx --> release/xxxx, feat/yyyy --> release/xxxx

  • 测试通过后，发起 merge request，待 code review 通过后，负责人 merge 代码，即 release/xxxx --> dev

上线流程

  • 确保所有研发分支 都已经 merge 到 release；

  • 使用 release branch 的代码进行测试，如果发现 bug，把对应的 bugfix merge 到 release，测试成功后合并至dev分支；

  • 在dev分支编译构建 使用脚本推送到 master 分支，抽包上线；(推送脚本往下看)

  • 发布完成后在当前的 dev branch 打上对应版本的 tag，master分支打上对应的上线文件版本的tag。

Bugfix 流程

  • dev的bug，直接检出 hotfix/xxx 修正,修复完成测试通过后，merge 进 dev 分支； 即 dev --> hotfix/xxxx --> dev

  • feat分支中的bug，直接在 feat/xxx 分支修复

其他

  • 如果涉及到版本同时迭代问题，叫上相关人员，一块讨论一下确定分支开发方案

  • 代码合并前是否需要代码评审，由项目负责人制定

  • 前端自动化能否基于gitlab-ci做持续集成

推送脚本

# -d 需要推送的上线文件目录
# -b 推送到master分支
# -e 把build目录推送到远端的目录下
$ gh-pages -d build -b master -e build
Edit this page