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，然后删除对应的迭代分支，完成本次迭代。