# git提交与发版流程

# 提交信息

按照: 类型 【功能/页面】 详细信息 进行代码提交

    // good
    新增【用户管理】页面
    // good
    新增【用户管理】用户编辑功能
    // good
    新增【用户管理】用户编辑,功能权限和数据权限表单项
    // good
    修改【用户管理】列表,所属角色列宽度
    // good
    删除【用户管理】列表操作列
    // good
    优化【用户管理】用户编辑弹窗提交按钮样式
    // good
    禁用【用户管理】用户编辑功能
    ...

# 分支合并与发版

目的:为了规范化发布流程,让发布工作更容易,制定了一个发布流程,可以避免出现发布各自的分支到仿真,争夺仿真环境资源的问题,同时规定了,不同的分支的不同用途,避免将无关的内容发布到正式环境。

WARNING

注意:每次仿真发版都需要在群内通知该项目组全员,避免意外的发版的干扰。

WARNING

目前前端发版一般使用运维团队提供的jenkins工具,我们与运维团队约定了使用jenkins工具打包发版时,前端项目的构建命令,如下(用于明确区分仿真和正式环境):

  • 仿真:npm run build:fz
  • 正式:npm run build:zs

发版前请确认好package.json中的scripts包含build:fz和build:zs脚本命令,已确保仿真和正式环境可以顺利打包构建

TIP

分支简介:

  • dev_姓名_任务名(迭代任务分支):开发人员从master创建新的迭代分支(以dev_开头 + 自己姓名的缩写 + 任务名称),完成迭代开发任务。

  • dev(测试分支):检查迭代内容无误后可以将迭代分支需要合并到dev开发测试分支,通过Jenkins发布到仿真环境,进行仿真测试。

  • release(发版分支):将待发版的迭代分支合并到release,填写发版清单和发版记录,通知组长和相关人员,发布正式环境。

  • master(稳定分支):release发版正式环境后,并且正式环境检查没有问题,将release并入master,然后删除对应的迭代分支,完成本次迭代。