Git - 分支管理策略

一千个项目可能有一千种 Git 分支管理策略。

​ —— 严士比亚·北

在不同的公司、项目里跌打滚爬过,你是否每次总在适应团队各种各样的 Git 操作规范?作为测试,若你的工作与持续集成有关,又是否因为不同的 Git 规范而头痛?

即使是本文介绍的分支管理策略,也不一定适合大家的项目,但我们长期使用下来,经过多次优化升级,一定不会难用。

研发流程与部署环境

为什么先说研发流程呢?分支通常可以对应研发流程中不同的部署环境:

​ tag -> 生产环境(production)

​ master -> 预发/灰度环境(pre-production/staging)

​ develop -> 测试环境(test)

​ feature -> 线下调试/开发环境

有很多同学分不清预发环境与测试环境区别,预发环境通常数据与线上一致,上线前在该环境用真实数据回归所有功能;测试环境通常用来验收feature

使用标签的必要性

很多人用 Git 只使用分支(Branch),不使用标签(Tag)。Git 官网对 Tag 的解释如下:

Like most VCSs, Git has the ability to tag specific points in a repository’s history as being important. Typically, people use this functionality to mark release points (v1.0, v2.0 and so on).

像其他版本控制系统(VCS)一样,Git 可以给历史中的某一个提交打上标签,以示重要。 比较有代表性的是人们会使用这个功能来标记发布结点(v1.0 等等)。

我建议分支除了 master 与 develop 分支外,其他分支都为临时分支,在开发完成后即删除。过多的分支会给你查找目标分支带来麻烦。

将版本与进行中的需求分开管理是标签与分支存在的意义。

Git流程之

开发与上线

1

Master 是最原始的分支。刚开始开发时,需要从 master 分支 checkout 一个develop 分支作为开发分支。Develop 分支相对 master 分支可能会存在一些 Bug,代码不如 master 分支稳定;

当有新特性或需要解决 Bug,则从 develop 分支 checkout 一个 feature 分支进行开发;

每个新特性开发完毕,就从 feature 分支发起 Merge request (MR) 请求合并到 develop 分支;

所有特性开发完毕并在测试环境测试通过,从 develop 分支发起 MR 请求合并到 master 分支;

在预发环境测试通过后,打个标签,正式发布上线。

解决线上Bug

2

线上出现 紧急 Bug 就不能有太长的测试发布流程了,通常可以这么做:

从 master 分支 checkout 一个 hotfix 分支,解决完 Bug 合并回 master 分支,在预发环境测试没问题后打标签发布;

发布完成后,不要忘了更新 develop 分支,因为此时 develop 分支落后于 master 分支,所以可以让 develop 分支 rebase master 分支。

解决feature分支冲突

3

这是最常见的一类场景,一个版本通常不止一个新特性。先开发完成的特性合并回 develop 分之后,会导致其他 feature 代码版本落后无法合并至 develop。

比较常见的解决方法是将 develop 分支合并到 feature2 分支,这样操作有个坏处,会产生冗余的git 日志:Merge branch 'develop' into feature2

更好的方法是用 Rebase(变基) 。在分支落后情况下,rebase develop 可以将当前分支的改动“接在” feature1 的改动之后。

注意:

  1. rebase 会修改 Git 历史提交记录,操作不当存在一定风险。
  2. rebase 后,需要 git push -ff (fast-forward模式) 才能将代码推送到远程仓库

代码流动原则

分支管理中,切记 代码只可单路径流动,意味着我们需要严格遵守下面的操作:

  1. 只能从 develop 分支 checkout feature 分支;
  2. Feature 分支 只能合并入 develop 分支;
  3. 有 hotfix 情况下,develop 必须 rebase master 分支,保持代码从 master 流动至 develop。
0%