1. 分支

分支	功能	生命周期	名称规则	分支操作流程	说明
master	归档分支	长期	master	develop --mr--> master	主要用来归档，保留每个版本的 tag，不能被 push,变更只能通过 merge 或者 rebase
develop	回归分支	长期	develop	feature --mr--> develop --create tag--> tag --mr--> master	主要用户回归测试，如果回归测试过程中发现bug，从 develop 创建 fix
feature	需求分支	临时	feature_{需求ID}_{版本日期}	task --mr--> feature --mr--> develop	根据需求从 develop 创建，使用完之后合并到 develop 并且删除当前分支
task	任务分支	临时	task_{需求ID}	user --mr--> task --mr--> feature	一个需求任务对应一个 task，同一个需求下的 task 分支从属同一个 Feature 分支，task分支在单人开发项目中是可以被省略的
user	个人分支	临时	yourname/xxx	code --pr--> task	个人开发分支

2. commit message

格式如下:

<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的脚注]

类型枚举

# 主要type
feat:     增加新功能
fix:      修复bug

# 特殊type
docs:     只改动了文档相关的内容
style:    不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build:    构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert:   执行git revert打印的message

# 暂不使用type
test:     添加测试或者修改现有测试
perf:     提高性能的改动
ci:       与CI（持续集成服务）有关的改动
chore:    不修改src或者test的其余修改，例如构建过程或辅助工具的变动

项目中推荐使用 commitlint 对 commit message 执行强制校验，推荐使用如下配置文件

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', [
      'feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore', 'revert'
    ]],
    'subject-full-stop': [0, 'never'],
    'subject-case': [0, 'never']
  }
}

3. code review

cr 必要性
- 代码，是设计理念落地的地方，是技术的呈现和根本。同学们可以在 review 过程中做到落地沟通，不再是空对空的讨论，可以在实际问题中产生思考的碰撞，互相学习，大家都掌握团队里积累出来最好的实践方式！
- 在编码过程中可以提前发现不符合业务逻辑或者质量不高的代码
- 高手可以直接指出新手代码中的问题，新手可以马上从高手的反馈中学习到好的实践，得到更快的成长
- 更快地了解业务
- 让团队规范得到执行
- 培养先设计再开发的习惯
cr 时机
- 开发者写下第一行代码就需要提交对应的 pr 到对应的评审者
- 按照功能粒度进行提交，复杂功能按天提交 pr
- 评审者要在测试工作完成之前审核完对应的 pr
- 建议：单个 pr 不能超过 8 个 commit，复杂的功能需要提前告知评审者
cr 谁来做
- 多人合作开发的项目由负责人进行 cr
- 单人项目可以找对应的业务负责人或者由对应的业务负责人指定人员进行 cr
- 项目负责人编写的代码由其他相关的业务负责人进行 cr
cr 做些什么
- 代码是否很容易理解
- 代码中是否有重复的地方
- 代码是否容易测试和调试
- 代码是否考虑到了非功能性需求，如性能、内存
- 代码是否过于庞大
- 代码格式是否遵循团队规范