背景：
现有git commit存在数量过多、非线性、信息不清等问题，为代码部分合并及功能历史追溯带来较大困扰，故需要一套git流程及commit规范。
流程规范
- 迭代开始时，3分及以上的item需基于迭代分支新建相应的功能分支
feature/xxx。 - 开发过程中需要临时切换分支时，尽量使用暂存
stash替代commit，避免无意义commit。 - 提交commit信息时，需带上teambition对应的item号，如没有对应item可留空。
- 在功能分支上开发完毕后，检查此分支上所有的commit log记录，使用
git rebase整理合并冗余信息，最终merge回迭代分支进行测试。 - 【前端】业务代码改动和设置的改动尽量分commit add，不要在同一次提交内。
- 使用
git cherry-pick合并代码后，git rebase整理合并信息
\
commit规范
commit message 包括两个部分：Header，Body
<id><type>: <subject>
// 空一行
<body>
Header（必填）
Header 包括三个字段：id（必填）、 type（必填）和 subject（必填）
id
功能或bug在teambition上对应的item号，使用<>包裹，如
type
type 用于说明 commit 的类别，只允许使用下面 7 个标识。
- feat：新功能（feature）
- fix：修补bug
- docs：文档（documentation）
- style： 格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
- chore：构建过程或辅助工具的变动
- merge：此次commit是一次merge
subject
subject 是 commit 目的的简短描述，不超过50个字符，与type之间需要用冒号分隔。
Body（选填）
Body 部分是对本次 commit 的详细描述，可以分成多行。
使用示例：
git commit -m '<ECM-7480>fix: 生产bug修复'
git commit -m '<ECM-7490>feat: 权限改造一期
1、架构改造，支持后续相关规划
2、增加“基础数据”模块权限
3、完善档案管理模块权限'
具体效果：
