分支使用规范

俗话说：没有规矩，不成方圆。遵循一个好的规章制度能让你的工作事半功倍。同时也可以展现出你做事的认真的态度以及你的专业性，不会显得杂乱无章，管理困难。Git分支规范也是一样。当遵循了某种约定的Git分支，在代码提交以及多开发、多分支协同工作的时候，必须遵循这个规范操作，否则不予以提交、合并代码、提测、上线等操作。

Git Flow有主分支和辅助分支两类分支，通常主分支也被称为长期分支。

主分支用于组织与软件开发、部署相关的活动；
辅助分支组织为了解决特定的问题而进行的各种活动。

主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。

主分支

master分支

master 分支存放的是随时可供在生产环境中部署的稳定版本代码
master 分支保存官方发布版本历史，release tag标识不同的发布版本
一个项目只能有一个 master 分支
仅在发布新的可供部署的代码时才更新 master 分支上的代码
每次更新 master，都需对 master 添加指定格式的 tag，用于发布或回滚
master 分支是保护分支，不可直接 push 到远程仓 master 分支
master 分支代码只能被 release 分支或 hotfix 分支合并

develop分支

develop 为开发分支，一般包含正在开发的所有新特性
develop 分支不能与 master 分支直接交互
develop 分支衍生出各个 feature 分支
develop 分支是保护分支，不可直接 push 到远程仓库 develop 分支
一个项目只能有一个develop 分支

注意：一般来说，我们会选择将 master 分支和 develop 分支作为长期分支，长期分支是不会被删除的，会和你的 project 项目共存亡。即除非你 project 不再需要了，否则，这两个分支切出来以后就永远都不允许删除。当然也有一些特例，比如某些公司会将 develop 分支也进行删除，只保留 master 分支。

辅助分支

辅助分支是用于组织解决特定问题的各种软件活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作、以及对版本代码的测试。这些分支与主分支不同，通常只会在有限的时间范围内存在。这个有限的时间范围比如说一个开发周期，规定在两个礼拜，那么到了第二个礼拜的最后一天开发周期完成，代码合并，该分支就应该被删除掉。

辅助分支包括：

用于开发新功能时所使用的 feature 分支
用于辅助版本发布的 release 分支
用于修正生产代码中的缺陷的 hotfix 分支

以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说，这些分支与 Git 其他分支并没有什么区别，但通过命名，我们定义了使用这些分支的方法。

feature分支

使用规范：

命名规则：feature/*或者 feature/JID-N/developerName
develop 分支的功能分支
feature 分支使用 develop 分支作为它们的父类分支
以功能为单位从 develop 拉一个 feature 分支
每个 feature 分支颗粒要尽量小，以利于快速迭代和避免冲突
当其中一个 feature 分支完成后，它会合并回 develop 分支
当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响 develop 分支
feature 分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里
feature 分支只与 develop 分支交互，不能与 master 分支直接交互

如有几个同事同时开发，需要分割成几个小功能，每个人都需要从 develop 中拉出一个 feature 分支，但是每个 feature 颗粒要尽量小，因为它需要我们能尽早 merge 回 develop 分支，否则冲突解决起来就没完没了。同时，当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响 develop 分支。
也正是因为可能多个同事协同开发同一个生命周期的项目的不同功能，因此我在上面 feature 分支命名中加入了第二种命名规则，JID-N 表示的是哪个任务ID号，developerName 表示开发者名称，用以方便区分是哪个任务下哪个开发者的分支。

release分支

使用规范：

命名规则：release/，“”以本次发布的版本号为标识
release 分支主要用来为发布新版的测试、修复做准备
当需要为发布新版做准备时，从 develop 衍生出一个 release 分支
release 分支可以从 develop 分支上指定 commit 派生出
release 分支测试通过后，合并到 master 分支并且给 master 标记一个版本号
release 分支一旦建立就将独立，不可再从其他分支 pull 代码
必须合并回 develop 分支和 master 分支

release 分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等）。通过在 release 分支上进行这些工作可以让 develop 分支空闲出来以接受新的 feature 分支上的代码提交，进入新的软件开发迭代周期。
当 develop 分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建 release 分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到 release 分支之内（避免由此引入一些不可控的系统缺陷）。
成功的派生了 release 分支，并被赋予版本号之后，develop 分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。

hotfix分支

使用规范：

命名规则：hotfix/*
hotfix 分支用来快速给已发布产品修复 bug 或微调功能
只能从 master 分支指定 tag 版本衍生出来
一旦完成修复 bug，必须合并回 master 分支和 develop 分支
master 被合并后，应该被标记一个新的版本号
hotfix 分支一旦建立就将独立，不可再从其他分支 pull 代码

除了是计划外创建的以外，hotfix 分支与 release 分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。
当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从 master 分支上指定的TAG 版本派生 hotfix 分支来组织代码的紧急修复工作。
这样做的显而易见的好处是不会打断正在进行的 develop 分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。

bugfix分支

修补分支：软件发布以后，难免会出现 bug。这时就需要创建一个分支，进行 bug 修补
修补 bug 分支是从 master 或 release 分支上面分出来的。修补结束以后，再合并进 master 和 develop 以及 release 对应版本分支。它的命名，可以采用 fixbug-*（日期）的形式。

tag使用规范

版本号(tag)命名规则：主版本号。次版本号。修订号，如2.1.13。(遵循 GitHub 语义化版本命名规范)
版本号仅标记于 master 分支，用于标识某个可发布/回滚的版本代码
对 master 标记 tag 意味着该 tag 能发布到生产环境
对 master 分支代码的每一次更新(合并)必须标记版本号
仅项目管理员有权限对 master 进行合并和标记版本号

代码提交规范

所有 commit 必须有注释，内容必须简洁明了的描述本次 commit 涵盖了哪些内容。严禁注释内容过于简单或不能明确表达提交内容的！
合理控制提交内容的颗粒度，一次 commit 含一个独立功能点。严禁一次提交涵盖多个功能项。
正确为每个项目设置 Git 提交用到的 user.name 和 user.email 信息，以公司邮箱为准，不可随意设置以影响无法正确识别。

git commit 日志规范

根据 angular 规范提交 commit，这样 history 看起来更加清晰，还可以自动生成 changelog。

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

type

提交 commit 的类型，包括以下几种
feat:新功能
fix:修复问题
docs:仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等
style:仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
refactor:代码重构，没有加新功能或者修复bug
perf:优化相关，比如提升性能、体验
test:测试用例，包括单元测试、集成测试等
chore:改变构建流程、或者增加依赖库、工具等
revert:回滚到上一个版本

scope

修改文件的范围（包括但不限于 doc, middleware, core, config, plugin）

subject

用一句话清楚的描述这次提交做了什么body
补充 subject，适当增加原因、目的等相关因素，也可不写。footer
当有非兼容修改(Breaking Change)时必须在这里描述清楚
关联相关 issue，如 Closes #1, Closes #2,#3
如果功能点有新增或修改的，还需要关联文档 doc 和 egg-init 的 PR，如 eggjs/egg-bin#123

示例：

fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.
Document change on eggjs/egg#123
Closes #392
BREAKING CHANGE:
  Breaks foo.bar api, foo.baz should be used instead

具体可查看文档

项目权限

Git权限分Maintainer、Developer、Reporter、Guest四种类型
Guest可以创建issue、发表评论，不能读写版本库
Reporter可以克隆代码，不能提交
Developer可以克隆代码、开发、提交、push
Maintainer可以创建项目、添加tag、保护分支、添加项目成员、编辑项目

更详细的项目权限说明请参考官方文档：GitLab Project成员权限

分支使用

每个Git项目固定含有上述分支类型。主分支master和develop是保护分支，只能进行合并请求，均不可直接提交代码;
feature分支作为代码开发分支，只能从developer check out；
功能需求或常规Bug修复，请从develop拉取feature分支；
线上紧急问题修复，请从master拉取hotfix分支。