俗话说：没有规矩，不成方圆。遵循一个好的规章制度能让你的工作事半功倍。同时也可以展现出你做事的认真的态度以及你的专业性，不会显得杂乱无章，管理困难。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- * （日期）的形式。
分支责任分工
分支 职责描述
master 运维人员：部署
develop 开发人员：维护， 部署
release 运维人员：部署
feature 开发人员 ：各模块自行创建、维护
bugfix 开发人员 ：修复bug，协助解决自动merge中发生的冲突
分支对应的环境
分支 环境
master/hotfix/bugfix 生产环境(release)
develop 开发环境(alpha)
release 预发布(RC)环境
我个人定义的规范
结合了Gitflow和workflow两者，根据公司情况稍作改变。

分支 环境
master pre(作为预发布环境，只允许从dev分支合并到该分支)
dev perf环境(作为测试环境，只允许从feature分支合并到该分支)
feature sit环境(作为开发环境，允许开发直接从本地提交代码到该分支)
分支命名规则：

master
dev/v1.0.0或者dev/week01
feature/JID-1/allenjol
feature分钟中，其中JID-1表示jira的id号，allenjol表示开发者英文名。

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。

提交 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 IE9Older IEs serialize html uppercased, but IE9 does not…Would be better to expect case insensitive, unfortunately jasmine doesnot allow to user regexps for throw expectations.Document change on eggjs/egg#123Closes #392BREAKING 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分支。