目录：
规范的种类
在大多数人的脑海中 Git规范 = Git Flow 或者 Git规范 = Git Flow + 提交规范。
这大概是因为从来没有人系统、深入地理解和总结过 Git 规范相关的所有东西。
为了以后在 Git规范 方面有更清晰的表达，我这里对 Git规范 相关的概念进行重新定义下。
我把 Git 相关的规范分为了以下几类（可能还不全，日后会慢慢完善）：
- 仓库层级结构规范：定义了仓库的分组（层级）结构及访问权限。
- 协作管理规范：定义了多人协作时的管理策略。
- 分支流转规范：定义了分支的来源、去向、合并、删除等相关的规则。
- 合并规范：定义了合并操作的具体规则。
- 合并请求规范：定义了合并请求的步骤、信息等相关规则。
- 提交信息内容规范（简称提交规范）：定义了提交文件的结构、格式、信息类型等规则。
- 分支命名规范：定义了分支名字结构、格式等相关规则。
- 标签命名规范：定义了标签名字和信息结构、格式、信息类型等相关规则。
仓库层级结构规范
详情请看仓库层级结构规范
仓库层级结构图
- 产品（组）：因为产品之间的关联性较强，所以后端仓库不一定是按产品来划分的，但前端大多数是按产品来划分的，所以，针对产品，需要将 前端仓库 和 后端仓库分开；
- 后端（组）
- 服务1（仓库）
- 服务2（仓库）
- 前端（组）
- 产品1（仓库）
- 产品2（仓库）
- 后端（组）
- 项目（组）：因为项目之间的关联性较弱，往往有各个的前端仓库和后端仓库，所以默认情况可以将前端仓库 和 后端仓库 放在一起；如果某个项目只有前端仓库，没有对应的后端仓库，那就不必为项目创建组。
- 项目1（组）
- 前端（仓库）
- 后端（仓库）
- 项目2（仓库）：由于没有后端，所以
项目2直接作为前端仓库来创建，不必再创建成组
- 项目1（组）
- 前端工具库（组）：用于存放封装的库、工具等；因为这些工具大部分是通用的，服务于开发人员的，所以本组的默认访问权限可设为
内部 internal，特殊的组或仓库除外；- 工具库1（仓库）
- 工具库2（仓库）
- 后端工具库（组）：用于存放封装的库、工具等；因为这些工具大部分是通用的，服务于开发人员的，所以本组的默认访问权限可设为
内部 internal，特殊的组或仓库除外；- 工具库1（仓库）
- 工具库2（仓库）
- 运维（组）：存放一些基础设施的项目，比如：监控系统、日志系统、脚本架工具、运维脚本等。
- 工具1（组）
- 前端（仓库）
- 后端（仓库）
- 工具2（仓库）：单独的工具，不分前后端，如：脚本等；
- 工具1（组）
仓库目录结构图
访问权限
一般情况，仓库或组的公开性有以下几种
- 私有
private：只有仓库或组的成员才可以访问； - 内部
internal：只有内部用户（登录的用户）才能访问； - 公共
public：公开的，所以有人员（登录的 和 未登录的）都可以访问；
- 所有的顶层组：均为内部可见，这样可以让大家知道都有哪些分类，以至于在创建项目或组时在地方可以创建；
- 对于顶层组内部的组或仓库：
- 工具库内部的组或仓库（内部 internal）：包括前端工具库 和 后端工具库
- 因为这些工具大部分是通用的，服务于开发人员的，所以本组内部的组或仓库的默认访问权限可设为 内部
internal，特殊的组或仓库除外； - 如果因些工具库的源码不方便暴露，但文档需要大家都能访问，可将其文档单独存放在一个仓库中，分别为源码 和 文档设置不同的访问权限；
- 因为这些工具大部分是通用的，服务于开发人员的，所以本组内部的组或仓库的默认访问权限可设为 内部
- 产品、项目内部的组或仓库 （私有 private）：由于 产品 和 项目 是公司重要资产，并且只需要相关人员对于源码了解，所以这些组内部的组或仓库的默认访问权限应设置为 私有
private； - 运维内部的组或仓库（私有 private）：运维相关的工具通常只有运维人员来维护，所以此组内部的组或仓库的默认访问权限应设为 私有
private
- 工具库内部的组或仓库（内部 internal）：包括前端工具库 和 后端工具库
一般情况下，仓库或组的成员角色有以下几种：
- 管理员：拥有仓库完整的权限
- 开发者：拥有提前、推送、拉取代码的权限
- 浏览者：只能查看仓库，不能提交、推送仓库；
- 对于公司的职员：
- 前端负责人拥有所有前端仓库的访问权限；
- 后端负责人拥有所有后端仓库的访问权限；
- 开发人员只有其所负责项目的开发者角色；
- 项目负责人拥有其所负责项目的管理员角色；
协作管理规范
我在 Git协作管理方案 中介绍多种 Git协作管理方案，不同方案有不同的适用场景，具体使用哪种方案，因项目和团队结构而定，但对于大多数小中型项目和团队而言，都比较适用下面2种方案：
如果这两种方案不太理想，您可以在 Git协作管理方案 这篇文章中找到你想要的答案。
Git协作管理方案 这篇文章中讲的比较抽象和通用，下面就针对 使用分支管理环境 且 支持合并请求 的项目仓库 来具化地描述下 开测预发协作管理方案 和 稳妥型开测预发协作管理方案 的协作流程：
约定下各角色所管理的分支：
- 开发组长：开发分支
- 测试者：测试分支
- 预发布者：预发布分支
- 发布者：发布分支
当需要往这些分支上合并代码时，都需要通过 合并请求 向对应的分支负责人申请。
因为 稳妥型开测预发协作管理方案 只是在 开测预发协作管理方案 的协作流程 上平加了 第6条，这是为了确保 开发分支 上包含了 发布分支 的全部代码，所以可以将 开测预发协作管理方案 和 稳妥型开测预发协作管理方案 的协作流程统一描述，如下：
协作流程：
- 开发者基于
开发分支创建功能分支； - 向开发组长发起 合并请求，并在标题上添加前缀
WIP标识； - 开发者在
功能分支上做开发； - 开发组长审查代码，对有问题的地方进行批注，并要求开发者改正；
- 当开发完毕后，相关人员在
功能分支上进行验收； - 验收通过后，把
开发分支上最新的变更合并进来； - 开发者自测；
- 自测试没问题后，去除合并请求的WIP前缀，并通知开发组长处理请求；
- 👉（稳妥型方案特有的步骤）开发组长将
发布分支上的新变更 合并到开发分支上。 - 开发组长确定没问题后，同意 合并请求，并执行合并操作；
- 开发组长向测试者发起 合并请求；
- 测试者同意请求并执行合并操作；
- 测试者进行测试；
- 测试者测试通过后，向 预发布者 发起 合并请求；
- 预发布者接受请求并执行合并操作；
- 预发布者在预发布环境测试；
- 预发布环境测试通过后，预发布者向 发布者 发起 合并请求；
- 发布者接受请求并执行合并操作；
开测预发协作步骤-简化版
分支流转规范
目前有以下几种分支流转规范（关于前三者之间的区别，可看 Git 工作流程 这篇文章）：
- Git Flow：适合基于 版本发布 的项目，即：需要一段时间以后才会产出一个新版本的项目。
- GitHub Flow：适合 持续发布 的项目。
- GitLab Flow：持续发布 和 版本发布 的项目都适合，且支持多种环境。
- Git并行工作流程规范: 适合经常有很多并行功能开发的项目。
个人比较推荐 GitLab Flow 和 Git并行工作流程规范。
分支命名规范
- 使用
/作为分隔符来表达层次关系；如模块/功能。- 相比 中划线
-、下划线_等其它的分隔符来说，/具有如下优势：- 与路径分隔符一致，从形式上更能表达出层级结构。
- 很多 git 工具会将
/解析分隔符并将分支名作为路径来解析，然后以文件树的形式展示分支，这样可以更好的组织分支。
- 相比 中划线
- 名称中应避免冗余信息；如
模块A/模块A_功能A中的模块A_功能A中的模块A就是冗余信息。
合并规范
- 开发分支只能合并当前迭代版本的功能；
合并请求规范
- 对于需要代码审查的分支，如果其直接下游分支是明确的，则该分支到直接下游分支的合并请求可以提前创建（比如在创建该分支时就创建到直接下游分支的合并请求），但此时合并请求的标题上应加上前缀
WIP（Work in progress 之意）标识，来表示该分支仍在开发中，当前状态不可合并；在真正开完成时，再移除前缀WIP标识，以表示当前分支处于可合并的状态；这样设计的目的是：- 可让合并请求的处理人员提前知道将来都有哪些分支需要合并；
- 合并请求的相关处理人员也可以提前做一些工作，比如：代码审查 等，而不用等到开完成时统一检查；在开发完成时再审查，往往审查的代码量太多，导致审查不完成 或 不仔细；
- 分支开发人员 和 合并请求处理人员可以在分支的开发期间连续互动（通过评审、审查等），以便及时发现问题、改正问题；
- 向
测试分支、预发布分支、发布分支发起的合并请求中一定要指定里程碑和标签； - 对于修复分支，一定要等到修复分支到母分支的合并请求合并完成之后，再继续执行合并到开发分支的后续操作，否则容易造成将开发分支上的代码合并到修复分支的母分支上；
- 合并请求合并完成后，要及时删除源分支；
标签命名规范
采用 语义化版本 规范来命名标签。标签的格式为：
<主版本号>.<次版本号>.<修订号>[.<测试版本号>]
- 主版本号：当你做了不兼容的 API 修改，
- 次版本号：当你做了向下兼容的功能性新增，
- 修订号：当你做了向下兼容的问题修正。
- 测试版本号： 当需要标明测试版本时可以在后面追加测试版本号，测试版本号可以使用测试轮数来指代。
- 先行版本号及版本编译信息可以加到
<主版本号>.<次版本号>.<修订号>的后面，作为延伸。
提交规范
详见 提交规范
网友评论