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 做些什么
-
代码是否很容易理解
-
代码中是否有重复的地方
-
代码是否容易测试和调试
-
代码是否考虑到了非功能性需求，如性能、内存
-
代码是否过于庞大
-
代码格式是否遵循团队规范
-
4. CHANGELOG 规范
版本日志跟随每一个上线版本更新，统一到一个 CHANGELOG.md 文件中，通常需要包含以下内容
-
当前版本的任务号
-
当前版本干系人
-
当前版本的时间节点
-
当前版本的需求概要
网友评论