Git 分支规范

• 活跃项目：近 2 个月内 GitLab 有代码提交
• 活跃分支：2022-04-01 后有 push 或 merge 的分支

WorkFlow

首先，强烈建议学习一下阮一峰的 Git 工作流程，以及文中提到的相关文章。

常见的 WorkFlow 有三种：

• Git Flow - 适用于单个人维护的项目
• GitHub Flow - 适用于比较简单的项目，迭代不频繁、发布环境/方式单一
• GitLab Flow - 能适用于各种场景

根据实际情况，每个团队/项目可以选择上面三种 WorkFlow 之一，不能过于随意。

无论选择上面哪种 WorkFlow，都要注意 保持 master 到 beta、release 等分支的同步，尽量使用 merge 而不是 cherry-pick，因为后者一但有遗漏会导致两份代码存在差异。

一些原则：

1. 线上发生 bug 时，从发生 bug 的 tag 开出 bugfix 分支
   修复后 merge 回原分支以及受影响的其它 master、release 以及 beta 等分支

2. feature 分支一般从 release 开出
   开发完成之后 merge 回 release 分支，上线后通过 release 分支 merge 回 master
   上线前 feature 分支的 bugfix 视为开发过程的一部分，在 feature 分支完成

3. bugfix、feature 等分支一般不再开出子分支

4. 除 master 以外，develop、test、beta、release 等其他任何分支不要长期使用
   例如长期持续使用 test/pro、beta/pro、release/pro 做 pro 环境的测试和发布，会导致它们可能与 master 分支存在差异、并且差异日积月累地增多，从而引发不必要的问题，正确的做法是：

5. 每个版本开始时，从 master 开出 test/pro-22.9.1、beta/pro-22.9.1、release/pro-22.9.1 等分支

6. 个人及 feature 分支 merge 到 test

7. 测试通过后从 feature merge 到 beta —— 因为 test 分支可能比较混乱

8. 上线时从 beta merge 到 release —— 确保 beta 环境和线上代码一样

9. 上线之后在 release 分支打 tag（例如 release/pro-22.9.1）、merge 回 master、然后删掉

{width=680px}

分支管理

为了配合 代码检查 以及适应各种 Git WorkFlow，Git 分支需要符合以下规范。

1. 开发分支

• 功能开发、bugfix、代码优化等开发分支应符合以下格式，开发完成后通过 merge request 合并到测试/发布分支
• 要求每个分支只能单一，不要把多个需求、以及与需求不相关的 bugfix 混在一个分支里
• 一般情况下禁止合并自己的 merge request

人员维度：

• 个人分支：<nickname>/<featrue-name | patch-name>，例如 ming/group-managers

类型维度：

• 需求分支：[featrue | fea]/<featrue-name>，例如 featrue/group-managers
• 修复分支：[patch | hotfix | fix | bugfix | bug | ...]/<patch-name>，例如 fix/my-page-columns

这些分支上的 push 可以不触发代码检查，但 无法作为 merge request 目标分支。

2. 公共分支

用于测试、发布的保护分支要设置为保护分支：

• root 分支：不带 / 的分支，建议使用规范命名，数量不超过 5 个，例如 master/main、develop、test、alpha、beta、release 等
• 测试/发布分支：带有前缀的分支 [test | release | stable]/[<version> | <environment> | <customer-name>]，例如 release/1.2.0、release/latest、release/PuXin、test/beta、test/HuaTu

这些分支上的 push/merge 以及 merge request 需要触发代码检查，test/* 可选。

3. 保护分支设置

设置：Project > Settings > Repository > Protected Branches

4. 定制分支

少量的可套用上面分支格式，发布分支需要强制检查，但 定制客户较多时建议 Fork 到新的仓库（代码可以 push/merge 会原仓库）

5. 历史分支

长期不用的分支建议打 tag 之后删除（从旧分支上创建名字符合规范的新分支，然后删除旧分支）

Code Review

在代码合并到 master、release 或 beta 分支时，需要通过 GitLab 的 merge request 流程进行 code review。

• 为了使分支的 graph 保持简洁，发起 merge request 之前最好执行 git reset --soft + git commit 或者 git rebase --autosquash，如果确实需要保留多条提交记录需要在 merge request 的备注里说明

• maintainer 在 merge 代码时，如果发现提交次数不是唯一，需要考虑勾选 squash commits 合并提交，并且无论如何都要勾选 delete source branch (必选)

• 小功能、bugfix 由 maintainer 独自或者叫相关 developer 一起 review，大块功能需要叫相关同学一起 reivew

SourceTree 里 Remote 设置 Optional extended integration —— Host Type 选 GitLab CE、Host 填 https://git.baijiashilian.com/，然后在 push 过的分支上右键即可 Create Pull Request；

版本规范

版本管理规范