概要说明
基本分支
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/ v e r s i o n 的分支,部署测试环境验证 o k 后,将 r e l e a s e / version 的分支,部署测试环境验证ok后,将 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