master 分支
master 分支为最稳定的分支，随时都是一个预备生产状态，因此不允许(可配置)直接向 master 分支 push 代码。理论上只能在 hotfix 分支、 release 分支达到稳定待发布的状态后才能将其 merge 进 master，然后标记一个版本号。查看 master 的提交历史，应该看到的是一个个版本 tag。 向 master merge 的方式只能通过 Pull Request。
dev 分支
与 master 分支并行的另一个分支，称为开发分支。我们的 task 分支基本都会合并到 dev 分支。同 master 一样，不能直接 push 代码到 dev 分支，需要通过 PR 的方式请求合并。
master 分支和 dev 分支都是关键分支，长期存在，而 release 分支、hotfix 分支、task 分支等辅助性分支只有有限的生命周期。
release 分支
命名规则为 release/版本号，当 dev 分支开发到一定程度后，需要进行发版测试，就从 dev 分支创建一个 release 分支并更新版本号。
这个 release 分支可能会存在一段时间，直到该发行版到达它的预定目标(测试通过)。在此期间，bug 的修复提交到该分支上(而不是提交到 dev 分支上)。在这里严格禁止增加大的新 features，他们必须合并到 dev 分支上，然后等待下一次大的发行版。
当 release 分支准备好成为一个真正的发行版的时候，需要将其 merge 到 master 并打上 tag，同样需要 merge 到 dev 以同步在 release 上修复的 bug。此外，如果不 merge 回 dev，下一次 release 版本合并到 master 时有可能冲突，如下: dev 分支在 B2 节点时创建了 release-v0.0.2 分支，将 package.json 的版本号由 0.0.1 修改为了 0.0.2(C 节点)，完结后将 release-v0.0.2 merge 回了 master(D 节点)，而没有 merge 回 dev。当 dev 分支前进到 B3 节点时创建了 release-v0.0.3 分支并将 package.json 的版本号 0.0.1 修改为了 0.0.3(E 节点)，release-v0.0.3 完结后将其合并到 master。可以预想到由于 release-v0.0.3 并不包含 master 的所有 commit(D)，而它们又修改了相同的内容，因此会出现冲突，此时只能 merge release-v0.0.2 到 dev，然后 release-v0.0.3 rebase dev(解冲突)，再重新合并到 master。
E release-v0.0.3
/
B1==>B2==>B3 dev
/ \
/ C release-v0.0.2
/ \
A==>B=========>D master
hotfix 分支
即热修复分支，当线上出现 bug 时，需要创建 hotfix 分支，命名规则为hotfix/task号，hotfix 分支可以基于 master 分支上对应线上版本的 tag 创建，也可以基于对应的 release 分支创建，创建后更新版本，待 bug 修复后 merge 回 master(需打 tag)和 dev。
task 分支
task 分支可以认为是为了开发某个功能而创建的分支，命名规则为task/task号，task 分支基于 dev 分支创建，task 分支最终都应合并到 dev 分支上。如下:
task 分支基于 dev 分支的 B commit 节点创建，又依次提交了 commit B1、B2、B3 后功能完成了，可以将 task 分支合并到 dev 了，但此时由于其他开发人员的提交 dev 分支已经到了 D 节点:
B1==>B2==>B3 task
/
A==>B==>C==>D dev
这时应该先进行rebase操作，再进行合并。
//在task分支上
$ git rebase dev
B1'==>B2'==>B3' task
/
A==>B==>C==>D dev
rebase 后就可以进行合并了，合并时应该使用--no-f的参数，该参数会将 task 分支所有提交合并到一起，与 dev 分支合并时产生一个新的提交，这能够保留 task 分支的提交信息，当出问题时更容易追溯是在做哪一个功能时导致的错误:
//git merge --no-f | //git merge
B1==>B2==>B3 task |
/ \ |
A==>B==>C==>D==>B' dev | A==>B==>C==>D==>B1==>B2==>B3 dev/task
Pull Requset 示例
步骤如下：
-
基于 dev 分支创建 task 分支
-
推送 task 分支到远程仓库
-
到仓库管理界面点击创建合并请求
无需 fork 仓库(团队内部成员而言)，直接在当前仓库提交即可。
-
选择要 PR 的分支并点击创建
需要注意的是”合并到“是选择 dev 分支，”拉取从“选择当前要请求合并的 task 分支。
-
撰写 PR 标题和内容并点击创建合并请求
PR 的标题和内容需要遵循一定的格式。
-
等待仓库 owner 通过 PR
owner 选择变基合并，拷贝 commit 信息。
PR 内容格式要求
标题
格式如下： 需要注意的是 task 与 subject 间的空格是必须要有的(否则自动生成 changelog 的工具无法识别)。
<type><task>: <subject>
例：
docs(T23321): add docs
-
type
其中 type 为以下固定的几种类型，用于说明 commit 的类别。
//type feat：新功能（feature） fix：修补 bug docs：文档（documentation） style： 格式（不影响代码运行的变动） refactor：重构（即不是新增功能，也不是修改 bug 的代码变动） test：增加测试 chore：构建过程或辅助工具的变动 -
subject
subject 是 commit 目的的简短描述。
-
task
task 部分是本次提交对应的 task 号。
内容
内容部分是对本次 commit 的详细描述，分条叙述。
1. 添加git-flow.md
2. 添加case-schema.md
