一千个项目可能有一千种 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的三个常见场景

开发与上线

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

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

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

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

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

解决线上Bug

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

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

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

解决feature分支冲突

这是最常见的一类场景，一个版本通常不止一个新特性。先开发完成的特性合并回 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。