Git 分支模型介绍

前言

当有 多个人一起协作开发时我们就会 用到Git ,但是只是简单用了它所提供的代码协作功能,但基于项目太小的特征:没有持久性、一次性开发,所以没有应到 Git 分支模型。然而在企业中,一个应用往往是有比较长的生命线,由很多个迭代项目开发构成,这时要解决几十甚至几百人的代码协作问题,就需要一套完整的规范的代码开发流程。

1.分支模型图解:

在这里插入图片描述

2.分支介绍

master :这个分支的代码是发布到生产的代码

develop :这个分支的代码是预发布到生产的代码

release :这个分支的代码是新版本发布到生产的代码

feature :这个分支的代码是新需求开发的代码

hotfix :这个分支的代码是紧急修复生产 bug 的代码

2.1 主分支(master, develop)

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

2.2 辅助分支(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 分支上去。

2.3 分支命名

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

master 主分支,发布分支

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

小写字母下划线形式

2.4版本号命名

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

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

每次发布生产(master),需要为master打一个tag,方便线上回滚

3.开发规范

3.1 Commit原则

  只要坚持做到以下几点就 OK 了:

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

3.2 Commit Message 格式

<type>(<scope>): <subject> (不超过50个字)

<空行>

<body> (每行不超过72个字)

<空行>

<footer>

type

feat:新功能(feature)
fix:修补bug
mod:修改(即不是新增功能,也不是修改bug的代码变动)
refactor:重构
docs:文档(documentation)
style: 格式(不影响代码运行的变动)
test:增加测试
chore:构建过程或辅助工具的变动
Scope
用来说明本次Commit影响的范围,即简要说明修改会涉及的部分。这个本来是选填项,但从AngularJS实际项目中可以看出基本上也成了必填项了。

Subject

用来简要描述本次改动,概述就好了,因为后面还会在Body里给出具体信息。并且最好遵循下面三条:

以动词开头,使用第一人称现在时,比如change,而不是changed或changes
首字母不要大写
结尾不用句号(.)
Body

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

Footer

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

Revert

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

feat: 增加用户权限功能

增加用户权限列表显示接口和用户权限编辑接口

BREAKING CHANGE: 删除了旧版登录验证接口
©️2020 CSDN 皮肤主题: 游动-白 设计师:上身试试 返回首页