分支管理
分支命名
master 分支
- master 为主分支,也是用于部署生产环境的分支,确保master分支稳定性
- master 分支一般由develop以及hotfix分支合并,任何时间都不能直接修改代码
develop 分支
- develop 为开发分支,始终保持最新完成以及bug修复后的代码
- 一般开发的新功能时,feature分支都是基于develop分支下创建的
feature 分支
- 开发新功能时,以develop为基础创建feature分支
- 分支命名: feature/ 开头的为特性分支, 命名规则: feature/user_module、 feature/cart_module
release分支
- release 为预上线分支,发布提测阶段,会release分支代码为基准提测
当有一组feature开发完成,首先会合并到develop分支,进入提测时,会创建release分支。
如果测试过程中若存在bug需要修复,则直接由开发者在release分支修复并提交。
当测试完成之后,合并release分支到master和develop分支,此时master为最新代码,用作上线。
hotfix 分支
- 分支命名: hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似
- 线上出现紧急问题时,需要及时修复,以master分支为基线,创建hotfix分支,修复完成后,需要合并到master分支和develop分支
常见任务
增加新功能
(dev)$: git checkout -b feature/xxx
# 从develop建立特性分支 (feature/xxx)$: blabla
# 开发 (feature/xxx)
$: git add xxx (feature/xxx)
$: git commit -m 'commit comment' (dev)
$: git merge feature/xxx --no-ff # 把特性分支合并到develop
修复紧急bug
(master)$: git checkout -b hotfix/xxx # 从master建立hotfix分支 (hotfix/xxx)
$: blabla # 开发 (hotfix/xxx)$: git add xxx (hotfix/xxx)
$: git commit -m 'commit comment' (master)
$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到master,并上线到生产环境 (develop)
$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到develop,同步代码
测试环境代码
(release)$: git merge develop --no-ff # 把develop分支合并到release,然后在测试环境拉取并测试
生产环境上线
(master)$: git merge testing --no-ff # 把testing测试好的代码合并到master,运维人员操作 (master)$: git tag -a v0.1 -m '部署包版本名' #给版本命名,打Tag
二、Git提交信息规范
当前业界应用的比较广泛的是 Angular Git Commit Guidelines
1 介绍
Git进行commit时都需要提交说明(commit message):
Git commit -m 'hello world'
-m参数就是用来指定commit message的
commit message应该清晰明了,说明本次提交的目的。
2 Commit message的格式
Commit message应该包括三个部分:Header/Body/Footer。其中,Header是必需的,Body和Footer可以省略。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
不管是哪一个部分,任何一行都不得超过72个字符(或100个字符)。这是为了避免自动换行影响美观
2.1 Header
只有一行,包含三个字段,type
(必须)、scope
(可选)和subject
(必须)
(1)type
用于说明commit的类别,只允许使用一下8个标识:
- feature:添加新功能
-
fix
:修补bug -
docs
:仅仅修改了文档 -
style
:仅仅修改了空格、格式缩进、逗号等等,不改变代码逻辑 -
refactor
:重构(即不是新增功能,也不是修改bug的代码变动) -
test
:增加测试用例 - performance: 增加代码进行性能测试
-
chore
:改变构建流程、或者增加依赖库、辅助工具等
(2)scope
用于说明commit影响的范围,比如数据层、控制层、视图层等,是项目不同而不同
(3)subject
是commit的简短描述,不超过50字符
例如fix: array parsing issue when multiple spaces were contained in string
.
- 义动词开头,使用第一人称现在时(change,而不是changed)
- 第一个字母小写
- 结尾不加句号(.)
2.2 Body
是对本次commit的详细描述,可以分成多行:
More detailed explanatory text, if necessary. Wrap it to
about 72 characters or so.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Use a hanging indent
有两个注意点:
1. 使用第一人称现在时
2. 说明代码变动的动机,以及与以前行为的对比
2.3 Footer
只是用与两种情况
(1) 不兼容变动
如果当前代码与上一个版本不兼容,则Footer部分以BREAKING CHANGE
开头,后面是变动的描述以及变动理由和迁移方法
BREAKING CHANGE: isolate scope bindings definition has changed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute' ,
}
After:
scope: {
myAttr: '@',
}
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
(2)关闭Issue
如果当前commit针对某个issue,那么可以在Footer部分关闭这个issue
Closes #123, #245, #992
2.4 Revert
有一种特殊情况,如果当前commit用于撤销以前的commit,则必须以revert:
开头,后面跟着被撤销的Commit的Header
revert: feature(pencil): add 'graphiteWidth' option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
Body部分的格式是固定的,必须写成·This reverts commit ·
Commitizen
一个撰写合格的Commit message的工具
安装:
npm install -g commitizen
然后,在项目目录里,运行下面的命令,使其支持 Angular 的 Commit message 格式。
commitizen init cz-conventional-changelog --save --save-exact
以后凡是用到 git commit 的命令,一律改为 git cz ,这时,就会出现选项,用来生成符合格式的Commit message。
validate-commit-msg
用于检查Node项目的Commit message是否符合格式,需要手动安装
首先拷贝这个JS文件到代码库,命名为validate-commit-msg.js
然后把这个脚本加入Git的Hook,在package.json
中使用ghooks,把这个脚本加为commit-msg
时运行
"config" : {
"ghooks" : {
"commit-msg" : "./validate-commit-msg.js"
}
}
然后每次Git commit时脚本就会自动检查Commit message是否合格,不合格就会报错
简单的示例
feature: 新增分析师清理功能
分析师清理功能,包括
1 . 查询分析师
2 . 分时段清理
不包含正文的提交说明
docs: correct spelling of CHANGELOG
包含作用域的提交说明
feature(lang): added polish language
为fix编写的提交说明,包含可选的issue编号
fix: minor typos in code
see the issue for details on the typos fixed
fixes issue #12
为什么使用约定式提交Commit message
- 自动化生成 CHANGELOG。
- 基于提交的类型,自动决定语义化的版本变更。
- 向同事、公众与其他利益关系人传达变化的性质。
- 触发构建和部署流程。
- 让人们更容易地探索结构化的提交历史,降低贡献项目的难度。
网友评论