关于Git Flow
工做流,我想已是老生常谈的话题了,可是今天我不得不来重温一下 Git Flow
工做流。当我看的代码厂库的时候,我已经开始怀疑人生。乱七八糟的分支,五花八门的提交信息,各类各样的分支名称,没有 Develop
分支,没有 Release
,也没有 Hotfix
。所以我想我应该好好温习一遍 Git Flow
工做流,来改善一下厂库现状。前端
其实 Git
不仅有 Git Flow Workflow
这一种工做流,还有 Fork Workflow
、Feature Branch Workflow
、Distributed Workflows
等。如今还有 Github Flow Workflow
和 Gitlab Flow Workflow
。git
Vincent Driessen 2010 年发布出来的他本身的分支管理模型。我的以为 Git Flow Workflow
应该是最经常使用的 Git
工做流了,更多的介绍你们能够看看这个 Git Flow Workflow (看完这一篇感受就不用再往下面看我写的这篇了,由于你已经重温了,嘿嘿)。bash
master
develop
master
:主分支,这个你们应该不陌生。代码库应该有一个、且仅有一个主分支;提供用户正式使用的版本,都在这个主分支上发布。 develop
:开发分支,平常使用的开发分支。从 master
分支上面分出来的,通常功能开发完成后合并到主分支,而且用主分支进行发布。工具
# 建立 develop 分支
git checkout -b develop master
# 切换到 master 分支
git checkout master
# 对 develop 分支进行合并(使用 --no-ff 能够在 git 历史上清晰看见记录)
git merge --no-ff develop
复制代码
feature
hotfix
release
feature
:功能分支。也就是你们作需求、功能的时候的分支。从 develop
分支上面分出来的,通常功能完成后合并到 develop
分支,而且删除功能分支。命名方式通常为 feature/*
或 feature-*
。# 建立 feature/x 功能分支
git checkout -b feature/x develop
# 切换 develop 分支
git checkout develop
# 开发完成后,将功能分支 feature/x 合并到 develop 分支(使用 --no-ff 能够在 git 历史上清晰看见记录)
git merge --no-ff feature/x
# 合并完成删除 feature/x 功能分支
git branch -d feature/x
复制代码
hotfix
:修补
bug
分支/补丁分支。
bug
这种东西你们都不陌生,
hotfix
就是用来修补正式发布之后的
bug
的分支。从
master
分支上面分出来的,通常修复完成后合并到主分支以及开发分支,而且删除补丁分支,用主分支进行发布。命名方式通常为
hotfix/*
或
hotfix-*
。
# 建立 hotfix/x 补丁分支
git checkout -b hotfix/x master
# 切换到 master 分支
git checkout master
# 修复完成后,将 hotfix/x 补丁分支合并到 master 分支(使用 --no-ff 能够在 git 历史上清晰看见记录)
git merge --no-ff hotfix/x
# 切换到 develop 分支
git checkout develop
# 将 hotfix/x 补丁分支合并到 master 分支
git merge --no-ff hotfix/x
# 对合并生成的新节点,作一个标签(后面重温 tag)
git tag -a 1.1
# 合并完成删除 hotfix/x 补丁分支
git branch -d hotfix/x
复制代码
release
:预发布分支。发布正式版本以前(开发完成 develop
分支合并到 master
分支以前),可能须要有一个预发布的版本进行测试。从 develop
分支上面分出来的,预发布结束之后,必须合并进 develop
和 master
分支。命名方式通常为 release/*
或 release-*
。post
# 建立 release/x 补丁分支
git checkout -b release/x develop
# 确认没问题后,切换到 master 分支
git checkout master
# 修复完成后,将 release/x 补丁分支合并到 master 分支(使用 --no-ff 能够在 git 历史上清晰看见记录)
git merge --no-ff release/x
# 切换到 develop 分支
git checkout develop
# 将 hotfix/x 补丁分支合并到 master 分支
git merge --no-ff release/x
# 对合并生成的新节点,作一个标签(后面重温 tag)
git tag -a 1.2
# 合并完成删除 release/x 功能分支
git branch -d release/x
复制代码
tag
是 git
版本库的一个标记,指向某个 commit
的指针。主要用于发布版本的管理,一个版本发布以后,咱们能够为 git
打上 v.1.0.1
、v.1.0.2
...这样的标签。版本代码被打上 tag
后就会被封存起来,之后就能够根据相应的 tag
找到对应的版本,防止版本代码丢失。测试
# 打一个 tag
git tag v1.0.1
复制代码
我想你们看到这里,不只把 Git Flow
重温了一遍,一些基础的 Git
命令也重温了一遍。ui
这个其实也是须要你们注意的,写好 Git
提交信息并不难,就看你们是否是想去养成这么一个习惯。 格式:spa
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
复制代码
Header
(必需):包括三个字段:type
(必需)、scope
(可选)和 subject
(必需)。3d
type
:用于说明 commit 的类别,只容许使用下面7个标识。指针
feat
:新功能(feature)
fix
:修补bug
docs
:文档(documentation)
style
: 格式(不影响代码运行的变更)
refactor
:重构(即不是新增功能,也不是修改bug的代码变更)
test
:增长测试
chore
:构建过程或辅助工具的变更
scope
:用于说明 commit
影响的范围,好比数据层、控制层、视图层等等,视项目不一样而不一样。
subject
:用于 commit
目的的简短描述,不超过50个字符。
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
复制代码
注意:
Footer
(可选): 1. 若是当前代码与上一个版本不兼容,则 Footer
部分以 BREAKING CHANGE
开头,后面是对变更的描述、以及变更理由和迁移方法。 2. 若是当前 commit
针对某个 issue
,那么能够在 Footer
部分关闭这个 issue
。 3. 若是当前 commit 用于撤销之前的 commit,则必须以revert:开头,后面跟着被撤销 Commit 的 Header。
状况一(示例):
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. 复制代码
状况二(示例):
Closes #234
复制代码
状况三(示例):
revert: feat(pencil): add 'graphiteWidth' option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
# Body部分的格式是固定的,必须写成This reverts commit <hash>.,其中的hash是被撤销 commit 的 SHA 标识符。
复制代码
公众号:前端曰
公众号ID:js-say
ps:是(yue)不是(ri)