Git 分支 - LD's BLOG | 个人技术学习

本文将介绍 Git 中的分支概念、相关操作，并介绍几种常见的分支工作流。

一、什么是分支？

几乎每一种版本控制系统都支持分支，分支意味着可以同时维护多条开发线路，从而实现多版本代码维护。

在很多版本控制系统中，分支是昂贵的，往往需要创建一个完整副本。

在 Git 中，分支是轻量的，分支的新建、删除、切换都可以在瞬时完成。从本质上来说，Git 中的分支是一个指向 commit 的指针。

merge 会将两个分支进行合并，产生一个新的提交对象。

需要注意的是：

rebase 会首先找到两个分支的共同祖先，提取出当前分支的所有修改，将这些修改都在原有分支之后重现。

需要注意的是：

rebase 能够将 Git 历史记录呈现为一条更平滑的链，使其更加整洁
rebase 可能破坏原始分支上的提交，因此应该在多人协作时谨慎使用
rebase 通常在提交前使用，具体来说：首先拉取代码进行开发，开发完成后，通过 git pull --rebase 将代码更新并将修改 “后移”，避免合入分支时的整合操作

GitFlow 通常包含以下五种分支：

Master 分支：主干分支；对应正式发布版本；通常情况下，只允许从其它分支合入代码，不允许直接提交代码
Develop 分支：开发分支；包含最新的开发代码
Feature 分支：特性分支；通常由 Develop 分支拉出；每个新特性的开发对应一个特性分支，用于开发人员开发并提交代码；Feature 开发完成后，应该合入 Develop 分支
Release 分支：预发布分支；当希望发布版本时，应该从 Develop 创建此分支，做测试环境测试，并且暂存可发布状态使得 Develop 分支可以继续开发；当测试结束后，应该将 Release 分支合并到 Master、Develop 分支，并删除 Release 分支
Hotfix 分支：热修复分支；生产环境发现新 Bug 时创建的临时分支，问题解决后，应该合入到 Master 和 Develop 分支

开发流程如下：

从 Develop 分支创建一个 Feature 分支，在 Feature 分支上进行新功能开发
开发完成后，将 Feature 分支合入 Develop 分支，做开发环境测试
从 Develop 分支创建一个 Release 分支，做测试环境测试，测试无问题后，将 Release 分支合并到 Master、Develop，删除 Release 分支
将 Master 分支部署至正式环境

GitHubFlow 通常只有一个固定的 Master 分支，并且该分支受保护，只有有用特定权限的人才能修改该分支。

开发流程如下：

如果希望开发新功能或修复 Bug，
- 假设有仓库的开发权限，应该从 Master 中拉取一个新分支，在这个新分支上进行开发
- 假设没有仓库的开发权限，应该 fork 原仓库，在新仓库上进行开发
功能开发完成后，创建 Pull Request（PR）
权限拥有者 review 这个 PR，
- 如果审核不通过，要求发起者进行修改
- 如果审核通过，同意请求，pull 后合并到原仓库

Pull Request，拉取请求，即请求仓库管理员进行代码的拉取

与 GitHubFlow 相比，GitLabFlow 增加了预生产分支 Pre-Production、生产分支 Production。其中，代码应该先合入 Master，再由 Master 合入 Pre-Production，再由 Pre-Production 合入 Production。

开发 Git