git workflow 规范

概要说明

基本分支

master、develop、release/xxx、hotfix/xxx、feature/dev_xxx

• master/release 分支，用来上线，打tag

• 从 master 分支拉一个 develop 分支，用来开发演进，合并代码，最终会 merge 到 master 上

• 从 develop 拉一个 feature/dev_xxx 分支，相关开发需求都提交到 dev_xxx 上，开发完了之后，merge 到 develop 部署测试环境，dev_xxx 分支合并到 develop 上之后删除 dev_xxx 分支，dev_xxx 分支一般都是临时功能开发用，合并后就没有保留的必要了

• develop 分支开发完了以后，基于 develop 分支开一个 release/$version的分支，部署测试环境验证ok后，将release/$version 合并到 master验证一下，然后打 tag 上线

其他说明

• master 分支是最稳定的，在 develop 分支开发稳定后，开一个 release 分支后 merge 到 master 上打tag
• dev_xxx 是功能开发分支，单人协作的时候，一般 merge 就可以。 如果是多人协作，那么一般自己本地的分支上开发提交，但是不 push 到远程，但是每次提交都 rebase 一下远程的 dev_xxx 分支。两个好处：
  • git log 的线会好看很多，少很多，看起来更方便
  • 冲突的概率会少很多，rebase 的时候，也不至于把自己的 commit 穿插到别人中，这样自己之前的 commit 在 rebase 后就是一个新的 commit 时间线

基准规范

基本分支规范

• 首先基于 master 分支创建 develop 分支

• 然后在 develop 分支基础上开一个 feature/xxx 的分支用来做开发

• 开发完新特性后 merge 到 develop；并且同时删除 feature/xxx

• develop 开发完了之后，基于 develop 创建一个 release/$version 支；用来 部署到 dev、pre 环境做测试

• release/$version 的 version 就是版本号名

• 测试 ok 之后，merge 到 master ，然后打 tag 上线

hotfix 规范

• 基于之前release/xxx 检出新的 hotfix/xxx 分支，然后修复验证后合并到 er 和 develop 分支
• 然后基于 master 再打 tag 上线

代码提交

• 提交的信息，全部采用英文
• 通过 commitizen 工具来提交（git cz 代替 git commit）
• 通过 standard-version 做版本发布和自动生成 Changelog

代码 code review

• feature/xxx 需要合并到 develop 的时候，通过 gitlab 创建一个 merge request ，然后指定其他同时或者上级领导，进行代码合并

• feature/xxx，要求尽可能少的代码提交，当一个小的功能完备后就需要 MR。

• 如果有大的功能特性，需要分步提交，方便 review