git workflow 规范

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 环境做测试
  • 测试 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


上一篇:工作中我是怎么使用git的--git教程 下


下一篇:chrome