工欲善其事，必先利其器。 众所周知“法律”是保护我们的“武器”。团队默认的规定也是事半功倍的“框架”废话不说，开撕。
团队Review内容
**团队技术和Code分享Review**
推进团队整体的技术沉淀与经验交流
促进核心模块功能业务分享与规范建设
Review形式
**每周组织一次**
线下＋线上腾讯会议相结合的形式
促进核心模块功能业务分享与规范建设
默许一个固定时间，错开重大会议一般周四、周五
Review顺序
**正常情况依次进行组织**
结合核心周会及近期线上高频问题反馈，插入高优内容分享安排
每次Review后，同步接下来要Review的伙伴提前准备
奖励机制
**伙伴需提前准备Review内容，并提前0.5天填写对应文档，无特殊原因按计划正常分享**
技术CodeReview优秀的伙伴：奖励周边1份/小礼品等等以示鼓励激励“将士”的士气
团队代码分支管理
规范目标
分支规范：保障功能代码上线安全和流程统一
代码规范：保障同技术栈团队新代码风格一致，防止劣化
规范原则：主体规范目标要统一化
执行细节：同时结合技术栈细节和历史现状细化后团队内同屏
落地节奏：版本开始执行，团按大版本迭代团队内自查优化
功能开发分支
独立功能或个人开发分支，以feature/开头，可独立提交代码，功能开发完上线后可删除。
格式要求：
如：feature/上线版本日期/ 开发者姓名、或独立需求名称
个人开发分支示例：
如：feature/20230328_Tony
独立需求分支示例：
如：feature/20230328_Teacher
提测上线分支
需求功能提测、发版上线专用分支，以如：releaseV/开头，
需要发MergeRequest，并找对应模块Owner进行Review；
发版上线后要Merge回Master分支并打Tag。
格式要求：
如：releaseV/上线版本日期
分支示例：
如：releaseV/20230328
WebBugFix分支示例：
如：releaseV/20230328_4.0_BugFix3
BugFix分支
发版上线后的BugFix专用分支，以releaseV/开头、_BugFix结尾，
需要发MergeRequest，并找对应模块Owner进行Review；
发版上线后要Merge回Master分支并打Tag。
格式要求：
如：releaseV/上线版本日期_BugFix
分支示例：
如：releaseV/20230328_BugFix版本不变市场审核小修改
如：releaseV/20230331_BugFix版本有问题需要大修改，各市场都要升级
master分支
需要发MergeRequest，并找对应模块Owner进行Review；
发版上线后要Merge回Master分支并打Tag。
主分支，用于部署生产环境的分支。
只能从其它分支（如release）合并。
需确保master分支稳定性、master分支存储了正式发布的历史属于只读唯一分支。
不能直接在此修改所有向master分支的Push推送都应当打TAG标签做记录,方便追溯。
MergeRequest保护分支
需要发MergeRequest，并找对应模块Owner进行Review；
发版上线后要Merge回Master分支并打Tag。
master
release/*
releaseV/*
分支提测
分支开发完成，拉取父分支的最新代码并向下合并；
合并完成后进行测试或提交测试；
测试通过后，合并回父分支。
代码提交 git Commit 使用规范
提交格式要求
Header：72个字符以内，描述主要变更内容
Body：更详细的说明文本。 需要描述的信息包括:
为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、
稳定性等等，他如何解决这个问题? 具体描述解决问题的步骤、是否存在副作用、风险?
完整示例
fix(route): 修复路由模块的一个bug
含有测试验证使用的临时代码，后续需要删除
bugID #435
简单示例（仅写必填项）：
fix: 修复路由模块的一个bug
Header 是必需的，Body 和 Footer 可以省略。
例外：含有 `Merge Branch` 或 `合并分支` 的msg会被忽略，不走检查
type
feat: 新功能（feature）
fix: 修复 bug
release: 发布新版本，更新tag
revert: 回滚到上一个版本
docs: 仅仅修改了文档，比如 README, CHANGELOG, CONTRIBUTE等等
style: 仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
refactor: 代码重构，没有加新功能或者修复 bug
perf: 优化相关，比如提升性能、体验
test: 测试用例，包括单元测试、集成测试等
chore: 改变构建流程、或者增加依赖库、工具等
commit 目的的简短描述，不超过50个字符。
修改ESLint配置文件 settings.json
自定义格式化配置 .eslintrc.js：
配置格式化忽略文件：如：/dist/、/node_modules/、 /public/
开发规范
组件命名规范
团队内部自定主要便于团队内部统一、降低后续维护
组件文件名应该始终以单词大写开头，组件名也是以单词大写开头，当多个单词拼写成的组件时，
单词开头大写，采用驼峰式命名规则。
组件应该都放到components文件夹下，单个页面独立一个文件夹，用来放相对应的vue文件以及
页面相关的样式文件，样式少可直接写到页面组件里边。
除index.vue 外其他文件使用大驼峰 例如： MyName.vue
项目文件命名
js、css、scss、html、ts
全部采用小写单词组成， 以下划线分隔。或者统一使用 “ 小驼峰 ” 写法
项目文件命名
规则和 “ 项目文件命名 ” 一致，但是有复数结构时，要采用复数命名法。
路由命名
路由命名采用全小写，单词用 - 隔开格式。
事件，方法命名规范
自定义方法分为很多种，一般用 handle 前缀, 如是一些判断方法，包含方法，获取值，设置值，则
分别有自己的前缀，采用前缀+Event事件名，驼峰命名形式
handle 大部分自定义方法前缀
has 是否包含某值方法前缀
is 是否为某个值
get 获取某值
set 设置某值
总结
以上表述只是框架模版，一切都是为了更丝滑的开发
莎士比亚曾经说过： 我在框架内我就是自由的人。
hhhh告辞各位。
