git workflow 规范

[TOC]

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

【"欢迎关注个人微信公众号：Linux 服务端系统研发，后面会大力经过微信公众号发送优质文章"】