Git
提交规范
- [Add] 增加新功能
- [Change] 改变需求
- [Fix] 修复错误
- [Update] 升级版本
- [Refactor] 重构代码
git-flow流程分支规范
- master
- develop
- feature
- release
- hotfix
master
只能用来包括产品代码。你不能直接工作在这个 master 分支上，而是在其他指定的，独立的特性分支中（这方面我们会马上谈到）。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。
develop
是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是开发的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到 master 分支中。
这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。
而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。
它们是根据需要来创建的，当它们完成了自己的任务之后就会被删除掉。
feature
每一个新功能从develop里创建出来的一个分支。
例如小明和小白分别做两个不相干的功能，就应该分别创建两个分支，
各自开发完以后，先后合并到develop里。
-
开始新功能
让我们开始开发一个新功能 “rss-feed”：
git flow feature start rss-feed -
完成一个功能
经过一段时间艰苦地工作和一系列的聪明提交，我们的新功能终于完成了：
git flow feature finish rss-feed -
之后，git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支，并且换到 “develop” 分支
release
当你需要一个发布一个新release的时候，我们基于develop分支创建一个release分支，完成release后，我们合并到master和develop分支
-
创建 release
当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时，这意味着：第一，它包括所有新的功能和必要的修复；第二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候开始生成一个新的 release 了：
git flow release start 1.0.0 -
完成 release
git flow release finish 1.0.0 -
这个命令会完成如下一系列的操作：
- 首先，git-flow 会拉取远程仓库，以确保目前是最新的版本。
- 然后，release 的内容会被合并到 “master” 和 “develop” 两个分支中去，这样不仅产品代码为最新的版本，而且新的功能分支也将基于最新代码。
- 为便于识别和做历史参考，release 提交会被标记上这个 release 的名字（在我们的例子里是 “1.1.5”）。
- 清理操作，版本分支会被删除，并且回到 “develop”。
hotfix
当我们线上应用出现了重大的bug，这时我们需要发布一个紧急修复版本，这时我们需要在 master 分支上拉出一个hotfix分支。
在bug修改好以后，要同时合并到master和develop
-
创建 Hotfixes
git flow hotfix start missing-link -
这个命令会创建一个名为 “hotfix/missing-link” 的分支。因为这是对产品代码进行修复，所以这个 hotfix 分支是基于 “master” 分支。
这也是和 release 分支最明显的区别，release 分支都是基于 “develop” 分支的。因为你不应该在一个还不完全稳定的开发分支上对产品代码进行地修复。
就像 release 一样，修复这个错误当然也会直接影响到项目的版本号！ -
完成 Hotfixes
git flow hotfix finish missing-link -
这个过程非常类似于发布一个 release 版本：
- 完成的改动会被合并到 “master” 中，同样也会合并到 “develop” 分支中，这样就可以确保这个错误不会再次出现在下一个 release 中。
- 这个 hotfix 程序将被标记起来以便于参考。
- 这个 hotfix 分支将被删除，然后切换到 “develop” 分支上去。