⽬的：快速⾼效协作，持续并发，稳定，⽆污染。
Warning: 命名严格统⼀ 全⼩写 只可存在⼀个⾮常规字符 “_”
版本号释义：
业务需求迭代采⽤版本号⾃增管理。 需在⽤户终端产品⾥标识。
eg: 1.0.0 前两位⽤于业务需求⾃增，后⼀位⽤于bug和紧急发版⽤。
分⽀释义：
master: 维护记录最新线上⽣产代码。当有合⼊更新，会发送全局通知到钉钉。merge操作仅限⾼级⼯程师以上⼈员。checkout不 限。
dev_业务名称：业务需求开发分⽀。从master检出。开发完成将⾃⼰合⼊到相应的release版本分⽀。在开发中，收到master更新通 知后，拉取master的代码merge到本地。上线后即可删除
细则提示：
单个业务块的需求 dev_业务名称(⽉⽇) eg: dev_order1130
多个业务改动较⼤的需求需拆分出多个开发分⽀ dev_业务块(⽉⽇) eg: dev_order1130
多个业务改动较⼩需求 dev_需求号 dev_land7571
release_v1.0.0: 版本交付分⽀。从master检出。 1.0.0 前两位⽤于业务需求⾃增。测试中，收到master更新通知后需同步代码。已 上线的release分⽀保留最后⼀个即可。
tag: 当release版本分⽀合⼊master后，从master分⽀create tag。命名：v版本号 eg: v1.0.0 代码提交管理
image.png
Commit 消息格式
<type>(<scope>): <subject> [bug number]
type（必须）：类别如下
feat：新功能
fix：修补bug [bug号]
ui： 样式
build：构建过程或辅助⼯具的变动
docs：⽂档（documentation）
perf: 优化和提升性能的改动
test：增加测试
ci: 与ci集成有关的改动
revert: 执⾏git revert打印的message
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
scope（必须）：模块。commit影响的模块范围。
subject（必须）: 更改描述
eg:
feat(订单):新增订单处理逻辑
fix(订单):订单接⼝更换[MUMSTAFF-1334]
代码提测管理
Git push:
feature提交：体现在提测单⾥。
optimize提交：必须评估影响范围告知测试体现在提测单⾥。
封板后：
原则上不允许push任何代码。
特殊bug情况需经理和负责⼈评估后决议。
网友评论