分支管理
软件的版本控制以及分支管理贯穿于整个软件产品的生命周期，日常的项目管理对于开发团队能否有节奏且顺利的交付软件也很重要。
分支管理规范
目前比较流行的分支管理模型有三个，即GitFlow、GitLabFlow、GitHubFlow。下面将介绍这三种分支模型的原理，使用场景和优缺点等。
GitFlow
GitFlow 是最早诞生并得到广泛应用的一种工作流程。
该模型中存在两种长期分支：master 和 develop。 master中存放对外发布的版本，只有稳定的发布版本才会合并到master中。 develop用于日常开发，存放最新的开发版本。
也存在三种临时分支：feature, hotfix, release。
feature分支是为了开发某个特定功能，从develop分支中切出，开发完成后合并到develop分支中。hotfix分支是修复发布后发现的Bug的分支，从master分支中切出，修补完成后再合并到master和develop分支。release分支指发布稳定版本前使用的预发布分支，从develop分支中切出，预发布完成后，合并到develop和master分支中。
优点：
feature分支使开发代码隔离，可以独立的完成开发、构建、测试feature分支开发周期长于release时，可避免未完成的feature进入生产环境
缺点：
- 无法支持持续发布。
- 过于复杂的分支管理，加重了开发者的负担，使开发者不能专注开发。
GitHubFlow
GitHubFlow分支模型只存在一个master主分支，日常开发都合并至master，永远保持其为最新的代码且随时可发布的。
- 在需要添加或修改代码时， 基于
master创建分支，提交修改。 - 创建
Pull Request，所有人讨论和审查你的代码。 - 然后部署到生产环境中进行验证。
- 待验证通过后合并到
master分支中。
这个分支模型的优势在于简洁易理解，将master作为核心的分支，代码更新持续集成至master上。根据目前收集到的反应来看，得到了更多的好评，认为GitHubFlow分支模型更加轻便快捷。
GitLabFlow
GitLabFlow 是GitFlow和GitHubFlow的结合,它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。
该模型采取上游优先的原则，即只存在一个master主分支，它是所有分支的上游。只有上游分支采纳的变动才能应用到其他分支。
- 对于持续发布的项目，建议在
master之外再建立对应的环境分支，如预生产环境pre-production，生产环境production。 - 对于版本发布的项目，建议基于
master创建稳定版本对应的分支，如stable-1，stable-2。
PaiFlow
凌云中台中我们采取了GitFlow的模式进行优化，并提供多种分支类型，主要流程如下：
凌云中采取了GitFlow的模式，并提供多种分支类型。
- 在领到日常功能开发任务时：
- 简单功能：基于
develop分支直接修改，自测通过后提交代码即可； - 复杂功能：基于
develop创建feature特性开发分支，提交代码后，合并至develop并删除feature分支。
- 简单功能：基于
- 在领到日常故障修复任务时:
- 简单故障：基于
develop分支直接修改，自测通过后提交代码即可； - 复杂故障：基于
develop创建bugfix故障修补分支，提交代码后，合并至develop并删除bugfix分支。
- 简单故障：基于
- 需要发版时，基于
develop创建release预发测试分支，生成的应用版本部署在UAT测试环境进行测试，期间若需要修改：- 简单整改：基于
release上直接处理，自测通过后并提交即可； - 复杂整改：基于
release创建bugfix整改分支，提交代码后，合并至release并删除bugfix分支。
- 简单整改：基于
- 正式发版时，将
release预发测试分支，合并到develop和master分支上，再基于master打一个标签, 如v1.0.0.0，删除release分支。 - 产品上线后发现故障需要紧急进行热修复时，则基于
tag(如v1.0.0.0)创建hotfix分支，将修复的代码提交至hotfix；部署该分支上的版本通过验收后，若master有更新的版本则需要基于hotfix打出热修版本的tag，如v1.0.0.1，若增加小功能则tag 为v1.0.1.0。 - 由于新版本的迭代也同时进行，所以需要在
hotfix上develop, 若master上无更新版本则需要同时合并到master，并基于master打出热修版本的tag，如v1.0.0.1,若增加小功能则tag 为v1.0.1.0, 将本次修改的提交合并至master和develop上，完成后删除hotfix分支。
分支命名规约
| 前缀 | 含义 |
|---|---|
| x.y.z-RELEASE | 用于发布正式稳定版分支 |
| master | 稳定版本主分支，从release-x.y.z合并进来 |
| develop | 开发主分支，最新的代码分支 |
| release-x.y.z | 预发布分支，测试验证后可直接发布的版本 |
| feature-x.y.z | 功能开发分支 |
| bugfix-x.y.z | 未发布bug修复分支 |
| hotfix-x.y.z | 已发布bug修复分支 |
核心原则：
- 版本发布是一个递进的过程
- 每个发布的特性或bug修需要进行测试再进行发布
- 小版本仅仅修复bug或仅改版本号进行透明升级的特性
提交命名规约
除了分支的名称需要规范，提交的命名也同样如此。猪齿鱼并没有把这个规则固化到系统中，需要团队共同遵守。
格式为：[操作类型]操作对象名称，如：[ADD]README.md，表示增加了README.md文件。
常见的操作类型有：
- [IMP] 提升改善正在开发或者已经实现的功能
- [FIX] 修正BUG
- [REF] 重构一个功能，对功能重写
- [ADD] 添加实现新功能
- [REM] 删除不需要的文件
版本号规范
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改。
次版本号：当你做了向下兼容的功能性新增。
修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
Git 仓库管理
华为云代码仓库
新建分支
基于 master 创建 develop 分支
设置默认分支
设置保护分支
Pai代码仓库
新建分支
最新版本 pai cli 创建的工程已默认创建了 master 和 develop 分支
旧项目使用 IDE 基于开发工具进行创建 develop 分支
设置默认分支
设置保护分支
启用分支保护-禁用推送
