版本管理操作规范及gitflow使用 | 张先生的网络日志

版本/分支管理规范，主要包括commit规范，版本号管理规范，mversion的使用方法，commitizen的使用方法，git常用命令收集，gitflow使用说明

1、有模板的项目，要以统一的模板创建项目

git clone git@git.com:your-project/your-project.git

1	git clone git@git.com:your-project/your-project.git

2、git commit 规范

git commit 提交样式标准

git commit -m "type(scope): 描述(#issue)"

1	git commit -m "type(scope): 描述(#issue)"

git commit -m "type(类型): 描述(#issue)"

<类型>

用于说明 commit 的类别，只允许使用下面7个标识。

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

<内容>

对本次 commit 的详细描述，可以分成多行，可详细说明代码变动的动机

<结尾>

如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue：

Closes #234

1	Closes #234

commitizen 使用说明

全局安装：

npm install -g commitizen

进入到.git目录

commitizen init cz-conventional-changelog --save --save-exact

用git cz命令来取代git commit

3、版本号规范

初期开发版本号从 0.1.0 开始

初次上线版本号更换为 1.0.0

使用npm install -g mversion更新版本号

npm install -g mversion

1	npm install -g mversion

版本号修改规则及命令：

v1.0.0 （主版本号.次版本号.修订版）

主版本号：当功能模块有较大的变动（不向下兼容），比如增加多个模块或者整体架构发生变化。

mversion m // 1.0.0 => 2.0.0

1	mversion m // 1.0.0 => 2.0.0

子版本号：当功能有一定的增加或变化（向下兼容），比如增加了对权限控制、增加自定义视图等功能。

mversion i // 1.0.0 => 1.1.0

1	mversion i // 1.0.0 => 1.1.0

修订号：一般是 Bug 修复或是一些小的变动（向下兼容），要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。

mversion p // 1.0.0 => 1.0.1

1	mversion p // 1.0.0 => 1.0.1

修改完成测试通过后在项目文档中写入更新内容，新建tag并推送到远程分支

可在.mversionrc中添加hooks自动添加tag

{
  "scripts": {
    "preupdate": "echo 'Bumping version'",
    "postupdate": "git add package.json && git commit -m v%s",
    "precommit": "echo 'precommit'",
    "postcommit": "echo 'postcommit'"
  }
}

{

"scripts": {

"preupdate": "echo 'Bumping version'",

"postupdate": "git add package.json && git commit -m v%s",

"precommit": "echo 'precommit'",

"postcommit": "echo 'postcommit'"

}

mversion文档

git tag -a v1.4 -m 'version 1.4'

git push --tags

4、常用命令

commit 统一规范

git commit -m 'type(scope): 描述(#issue)'

1	git commit -m 'type(scope): 描述(#issue)'

切换到指定tag

git checkout tag_name

1	git checkout tag_name

使用git tag命令添加一个新的标签：

git tag -a v1.4 -m 'version 1.4'

1	git tag -a v1.4 -m 'version 1.4'

删除本地tag：

git tag -d tag_name

1	git tag -d tag_name

从指定tag新建分支

git checkout -b branch_name tag_name

1	git checkout -b branch_name tag_name

clone指定tag

git clone --branch [tags标签] [git地址]

1	git clone --branch [tags标签] [git地址]

5、Git 命令

Git 命令收集

Tag 操作

6、Git flow

新项目第一次必须执行

git flow init

分支操作说明

feature新功能开发：从dev新建feature分支开发完成后会合并到dev

git flow feature start [version]

some commit…

git flow feature publish [version]

git flow feature finish [version]

git push

release：从dev新建release分支 -> 最后会合并到master和dev -> 发布新版

git flow release start [version]

mversion p // 更新版本号

some commit…

git flow release publish [version]

git flow release finish [version]

git push --all && git push --tag

修复线上bug：从master新建hotfix分支 -> 合并master和dev -> 发布新版

git flow hotfix start [version]

mversion p // 更新版本号

some commit…

git flow hotfix publish [version]

git flow hotfix finish [version]

git push --all && git push --tag

7、GitFlow的常用分支

master

主分支 , 产品的功能全部实现后 , 最终在master分支对外发布
该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支修改
另外所有在master分支的推送应该打标签做记录,方便追溯
例如release合并到master , 或hotfix合并到master

develop
主开发分支 , 基于master分支克隆
包含所有要发布到下一个release的代码
该分支为只读唯一分支 , 只能从其他分支合并
feature功能分支完成 , 合并到develop(不推送)
develop拉取release分支 , 提测
release/hotfix 分支上线完毕 , 合并到develop并推送

feature
功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发
功能开发完毕后合到develop分支(未正式上线之前不推送到远程中央仓库!!!)
feature分支可同时存在多个 , 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除

release
测试分支 , 基于feature分支合并到develop之后 , 从develop分支克隆
主要用于提交给测试人员进行功能测试 , 测试过程中发现的BUG在本分支进行修复 , 修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag
属于临时分支 , 功能上线后可选删除

hotfix
补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复
修复完毕后合并到develop/master分支并推送 , 打Tag
属于临时分支 , 补丁修复上线后可选删除
所有hotfix分支的修改会进入到下一个release