三张图助你掌握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的三个常见场景

开发与上线

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。

---