branch management 分支管理

env 环境

一般而言，分支至少应跟随对应正式环境、预发布环境、开发环境

  • master

主分支，作为线上环境的稳定版本

  • release / preview

基于 master 分支创建，对应预发布环境，便于项目人员做发布前的回归测试等

  • develop

基于 master 分支创建，开发阶段均基于由此分支创建自己的任务分支

基本命名规范

合理的分支命名，可以第一直观地表明分支功能，便于 code review 以及后续维护等

${CommitType}-${Version}-${TaskName}

  • CommitType 对应提交类型，表明分支功能
  • Version 对应版本
  • TaskName 对应任务名

Flow 工作流

  1. 经过项目评审及任务分配后，对应人员基于 develop 分支创建对应的任务分支
  2. 完成开发并自测后，交付测试进行初次验收
  3. 自测及测试验收完成，提交 Pull Request ，经 code review 后合并至 release/preview 分支
  4. 产品于预发布环境进行功能验收，确认无误后由进行回归测试
  5. 执行 git tag 标记相关 commit，将 release/preview 分支内容合并至 master 分支

git commit

Conventional Commits

合理规范的git操作可以使 GitFlow 变得清晰，便于生成CHANGELOG，便于 code review 与代码回滚等操作

  • git commit -m [message]

基本的commit命令，为代码提交填写简要的描述[message]

  • git commit --amend

修改最近一次commit的信息

  • git commit

进入文本编辑器书写详细的commit message

  1.   # 基于Conventional Commits规范，完整的commit格式如下
  2.   # Header 必须的，省略body和footer为上述[message]内容
  3.   <type>(<scope>): <subject> 
  4.   // 空一行
  5.   # 详细描述
  6.   <body> 
  7.   // 空一行
  8.   # 补充说明，例如关闭Issues、破坏性改动BREAKING CHANGE、撤销commit操作Revert:
  9.   <footer> 
  11.   # example
  12.   feat(module): add something
  1. type 提交类型

    建议性规范

类型 描述
feat: feature 新功能
fix: bug修复
docs: document 文档
style: 格式/样式（不影响代码运行的变动）
refactor: 重构
perf: 性能优化
test: 增加测试
chore: 构建过程或辅助工具的变动
ci: CI/CD工具的改动
revert: commit 回退
  1. scope 范围（可选）

用于说明 commit 影响的范围或模块，视项目及commit颗粒度情况自行处理

  1. subject 简要描述

不同于< body >，subject是简介明了的，且不超过50个字符

Note：git commit默认使用nano编辑器，可以将其替换成vi/vim编辑器

  1.   # 手动添加
  2.   cd ur-project && vim .git/config
  3.   # 向core中添加以下内容并保存
  4.   editor = vi/vim
  5.   # :wq
  7.   # 使用命令行
  8.   git config core.editor vi/vim

Git Hooks

husky