git 工作流程

发表于 分类于
本文字数： 1.4k 阅读时长 ≈ 1 分钟

概述

git 作为一种源码管理系统，不可避免地涉及到多人协作。为提升项目开发效率，若干种规范化的工作流程 (workflow) 被提出。

本文之中，我们介绍三种常见的工作流程：Git Flow、Github Flow、Gitlab Flow。

Git Flow

图一：Git Flow 工作流程

Git Flow 之中，master 分支和 develop 分支为两个长期分支；其余分支均为短期分支，相关功能开发完成后，其将被合并至长期分支。

  • master 分支

    用于存放对外发布的稳定版本。它只能通过合并其他分支而得到。

  • develop 分支

    用于存放项目开发的最新版本。当向项目中添加新功能时，就会新建 feature 分支，随后在此分支中开发功能。功能开发及测试完成后，此分支就会被合并至 develop 分支。

  • feature 分支

    用于开发某个功能点。

  • release 分支

    当管理人员认为 develop 分支所代表的项目功能已经开发完成，此分支就会被合并至 release 分支。测试人员在此分支上进行最终测试，如果通过测试则合并至 master 分支。

  • hotfix 分支

    当稳定版本发现 Bug，管理人员便会生成 hotfix 分支以紧急修复，随后将其合并至 master 分支和 develop 分支。

Git Flow 具有如下优缺点：

  • 优点

    分支清晰、可控。

  • 缺点

    分支众多，比较复杂。

对于 Git Flow 而言，长期分支 develop 用于开发，涉及频繁操作；长期分支 master 用于发布，不定期产生稳定版本。鉴于两者的使用频率不同，该种工作流程适用于“版本发布”类型的项目 (不定期上线新版本)。

Github Flow

鉴于 Git Flow 过于麻烦，Github Flow 被提出。它是一个简化版的 Git Flow，其中仅有一个长期分支—— master 分支。

图二：Github Flow 工作流程

Github Flow 的使用流程如下：

  1. 根据需求，从 master 拉取新分支。
  2. 新分支功能开发完成后，向 master 发起 pull merge 请求。
  3. master 负责人测试新分支功能，如果没有问题，可合并其至 master。

对于 Github Flow 而言，长期分支 master 不仅用作开发，也用作发布，即 master 分支的开发与发布是同步的。鉴于此，该种工作流程适用于“持续发布”类型的项目。

可以看到，这种工作流程十分适用于开源项目，但是极大概率不适用于公司项目 (毕竟开发和发布之间往往存在间隔)。

Gitlab Flow

Gitlab Flow 综合了 Git Flow 和 Github Flow 两者的优点，从而使得其可同时适用于“版本发布”类型和“持续发布”类型的项目开发。

Gitlab Flow 的最主要原则为 **上游优先 (upstream first)**，即 master 分支为所有其他分支的上游分支，当下游分支出现 Bug 时，其会开启分支进行修复，随后将此分支合并至 master 分支，master 分支再往出现 Bug 的分支合并其内容。

持续发布

对于“持续发布”类型的项目而言，Gitlab Flow 建议：除 master 分支外，建立其他环境分支。例如，master 分支用于开发环境、pre-production 分支用于预发环境，production 分支用于生产环境；且master 分支为 pre-production 分支的“上游分支”，pre-production 分支为 production 的“上游分支”。

版本发布

对于“版本发布”类型的项目而言，Gitlab Flow 建议：每发布一个稳定版本，就从 master 分支中拉取一个分支。

相关文章