版本管理操作规范及gitflow使用

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

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

1	git clone [email protected]:your-project/your-project.git

git commit 规范

git commit 提交样式标准

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：

1	Closes #234

commitizen 使用说明
全局安装：

npm install -g commitizen

进入到.git目录

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

用git cz命令来取代git commit

版本号规范

初期开发版本号从 0.1.0 开始

初次上线版本号更换为 1.0.0

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

1	npm install -g mversion

版本号修改规则及命令：

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

主版本号：当功能模块有较大的变动（不向下兼容），比如增加多个模块或者整体架构有较大改动的情况
1
mversion m // 1.0.0 => 2.0.0
子版本号：当功能有一定的增加或变化（向下兼容），比如增加了对权限控制、增加登录校验……
1
mversion i // 1.0.0 => 1.1.0
修订号：一般是Bug修复或是一些小的变动（向下兼容），要经常发布修订版，时间间隔短
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'"
    }
}

mversion 文档

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

git push --tags

常用命令

commit统一规范

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

切换到指定 tag

1	git checkout tag_name

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

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

删除本地tag：

1	git tag -d tag_name

从指定 tag 新建分支

1	git checkout -b branch_name tag_name

clone 指定 tag

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

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

Git Flow 的常用分支

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