Git分支模型和开发规范

1.分支管理

1.1 总览

image

从上图可以看到主要包含下面几个分支:

  • master: 主分支,主要用来版本发布。
  • develop:日常开发分支,该分支正常保存了开发的最新代码。
  • feature:从develop分支fork,合并回develop。具体的功能开发分支。
  • release:从develop分支fork,合并回develop和master。一般用于发布正式版本之前(即合并到 master 分支之前),需要有的预发布的版本进行测试。
  • hotfix:从master分支fork,合并回develop和master。线上 bug 修复分支。

1.2 主分支(master, develop)

主分支包括 master 分支和 develop 分支。master 分支用来发布,HEAD 就是当前线上的运行代码。develop 分支就是我们的日常开发。使用这两个分支就具有了最简单的开发模式:develop 分支用来开发功能,开发完成并且测试没有问题则将 develop 分支的代码合并到 master 分支并发布。

1.3 辅助分支(feature , release, hotfix)

    feature 分支用来开发具体的功能,一般 fork 自 develop 分支,最终可能会合并到 develop 分支。一般feature分支都存在于开发者本地,开发期间使用git rebase来保证和develop分支的代码同步并解决冲突。功能开发完毕后push到远程仓库,然后提交pull request,合并到develop分支。

    release 分支在我看来是 pre-master。release 分支从 develop 分支 fork 出来,最终会合并到 develop 分支和 master 分支。合并到 master 分支上就是可以发布的代码了。有人可能会问那为什么合并回 develop 分支呢?很简单,有了 release 分支,那么相关的代码修复就只会在 release 分支上改动了,最后必然要合并到 develop 分支。比如,当开发一个较长期的feature不着急上线但又需要部署测试时,可以从develop分出一个release分支,feature提交pull request到这个release分支,然后部署这个release分支到测试服。

    hotfix 分支用来修复线上 bug。当线上代码出现 bug 时,我们基于 master 分支开一个 hotfix 分支,修复 bug 之后再将 hotfix 分支合并到 master 分支并进行发布,同时 develop 分支作为最新最全的代码分支,hotfix 分支也需要合并到 develop 分支上去。

1.4 分支命名

除了主要分支的名字是固定的之外,派生分支是需要自己命名的,这里就要有个命名规范了。强烈推荐用如下形式:

  • master 主分支,发布分支
  • dev 主分支,开发分支
  • feat_xxx——按照功能点(而不是需求)命名;
  • release_xxx——用发布时间命名,可以加上适当的前缀;
  • hotfix_xxx——GitLab 的 issue 编号或 bug 性质等。

小写字母下划线形式

1.5 版本号命名

格式为:x.y.z,其中,x 用于有重大重构时才会升级,y 用于有新的特性发布时才会升级,z 用于修改了某个 bug 后才会升级。

v1.1.1:第一位大版本号,大功能发布时增加,技术负责人审核;第二位小版本号,增加小特性时增加,主开发审核;第三位BUG修复号,修复BUG用,修复人员负责。

  • 每次发布生产(master),需要为master打一个tag,方便线上回滚
  • 提交时的粒度是一个小功能点或者一个 bug fix,这样进行恢复等的操作时能够将「误伤」减到最低;
  • 用一句简练的话写在第一行,然后空一行稍微详细阐述该提交所增加或修改的地方;
  • 不要每提交一次就推送一次,多积攒几个提交后一次性推送,这样可以避免在进行一次提交后发现代码中还有小错误。

1.6 Commit Message 格式

():  (不超过50个字)

<空行>

 (每行不超过72个字)

<空行>

  • type
    feat:新功能(feature)
    fix:修补bug
    mod:修改(即不是新增功能,也不是修改bug的代码变动)
    refactor:重构
    docs:文档(documentation)
    style: 格式(不影响代码运行的变动)
    test:增加测试
    chore:构建过程或辅助工具的变动

  • Scope
    用来说明本次Commit影响的范围,即简要说明修改会涉及的部分。这个本来是选填项,但从AngularJS实际项目中可以看出基本上也成了必填项了。

  • Subject
    用来简要描述本次改动,概述就好了,因为后面还会在Body里给出具体信息。并且最好遵循下面三条:
    1、 以动词开头,使用第一人称现在时,比如change,而不是changed或changes
    2、首字母不要大写
    2、结尾不用句号(.)

  • Body
    里的内容是对上面subject里内容的展开,在此做更加详尽的描述,内容里应该包含修改动机和修改前后的对比。

  • Footer
    footer里的主要放置不兼容变更和Issue关闭的信息

  • Revert
    此外如果需要撤销之前的Commit,那么本次Commit Message中必须以revert:开头,后面紧跟前面描述的Header部分,格式不变。并且,Body部分的格式也是固定的,必须要记录撤销前Commit的SHA值。

示例

feat: 增加港股经纪商队列

增加港股经纪商队列接口和后台名称编辑接口
增加同时获取买卖盘和经纪商的接口

BREAKING CHANGE: 删除了旧版十档买卖盘接口

原文地址>>>

你可能感兴趣的:(Git分支模型和开发规范)