Home / Questions / 61657
Accepted
UselesssCat
Asked: 2020-04-09 18:25:00 +0800 CST 2020-04-09 18:25:00 +0800 CST

Git Flow 和 Github Flow 有什么区别？

  • 772

我一直在阅读，我已经知道Git 流程存在一段时间了。我对这个流程或多或少的了解，但是现在我发现Github流程和之前的流程不一样?。我知道 Git 流程提出了 master（生产）、develop、features/*、hotfix/* 和 release 分支。我已经进入了Github 流程指南，但我还没有完全理解它是如何工作的。

我想知道这两者之间有什么区别，或者实际上，什么是 github 流？我看到有很多英文文章，但没有西班牙文。

git

2 Answers

  1. 简单。

    混帐流

    在 git-flow 中，多个分支以不同的目标进行管理，例如，有一个开发分支、一个发布分支、一个或多个功能分支、补丁等。

    该流程表明您从一个或多个功能开始，然后继续开发，然后掌握，然后发布。

    feature -> develop -> master -> release

    这个循环的每个阶段都携带相同的拉取请求过程，并与下一个直接分支合并。

    这意味着当一个特性准备好时，它会被合并到开发分支中。一旦发布（例如）所需的所有功能都准备好，开发分支将与主分支合并。最后，在发布分支中发布了一个新版本。

    GitHub流

    在 GitHub 上有一条关于 master 分支的原则是： master 分支总是有效的。

    此外，它利用标签（某个分支中的特定点）和作为所选标签快照的发布功能，这使您可以轻松创建这些发布。

    虽然请求 -> 审查 -> 合并过程存在于 GitHub Flow 中，但它更简单，因为它们不经过连续的开发分支。

    GitHub 建议一旦批准，所有开发分支都转到master并且通过发布标签和快照完成发布。

    当然，这两个系统都是可选的。在我看来，GitHub 流程最适合小型团队或个人开发人员。GF对我来说似乎更专业，但也更复杂。

    • 6
  2. Best Answer

    Git-flow 是一个管理 Git 更改的过程，由 Vincent Driessen 创建，并附带一些 Git 扩展来管理该流。

    git-flow 背后的总体思路是拥有几个始终存在的独立分支，每个分支都有不同的用途：master、develop、feature、release 和 hotfix。

    在最终发布之前，开发功能或错误的过程会从一个分支流向另一个分支。

    一些受访者表示他们通常使用 git-flow。有些人从 git-flow 开始并远离它。

    离开的主要原因是 git-flow 流程在连续（或接近连续）部署模型中难以管理。总体感觉是 git-flow 非常适用于更传统的发布模型中的产品，其中每隔几周发布一次，但是当您每天发布一次或更多时，这个过程会大大中断。.

    你从一个尽可能简单的模型开始（就像 GitHub-flow 倾向于那样），如果有必要，你可以逐步建立一个更复杂的模型。

    您可以在“A Simple Git Branching Model”中看到一个基于 GitHub-Flow 的简单工作流的有趣插图，主要元素是：

    1. Master 必须始终是下拉菜单。
    2. 通过功能分支进行的所有更改（拉请求+合并）
    3. “rebase”以避免/解决冲突；加入大师在此处输入图像描述
    • 5