Git-flow 和 github-flow 的优缺点是什么？

小开

最佳答案

正如《 GitMinutes 》第17集中所讨论的，Nicholas Zakas在他关于“ GitHub 在公司内部的工作流”的文章中所说:

Git-flow 是一个用于管理 Git 中的变更的过程，由 Vincent Driessen 创建，并伴有一些接发用于管理该流。
Git-flow 背后的总体思想是有几个总是存在的独立分支，每个分支都有不同的用途: master、 develop、 feature、 release和 hotfix。
在最终发布之前，特性或 bug 的开发过程从一个分支流向另一个分支。

一些受访者表示，他们一般使用 git-flow。
有些人开始使用 git-flow，然后离开了它。

转移的主要原因是 git-flow流程很难在连续(或接近连续)的部署模型中处理。
一般的感觉是，git-flow在更传统的发布模式下工作得很好，每隔几周发布一次，但是当你每天发布一次或者更多的时候，这个过程就会大打折扣。

简而言之:

从一个尽可能简单的模型开始(就像 GitHub 流一样) ，如果需要的话，可以转向一个更复杂的模型。

你可以在下面看到一个基于 GitHub-Flow的 很简单工作流的有趣示例:
「 一个简单的 git 分支模型」，主要内容包括:

master必须始终是可部署的。

所有通过特性分支进行的更改(pull-request + merge)

Rebase 以避免/解决冲突; 合并到 master

对于一个实际的更完整和健壮的工作流，参见 < strong > gitworks (一个单词)。

小开

我已经使用 git-flow 模型一年多了，没问题。

但这实际上取决于如何开发和部署应用程序。

如果应用程序的开发/部署流程缓慢，那么它就能很好地工作。

但是举例来说，像 GitHub 一样，我们有一个具有快速开发/部署流程的应用程序，我们每天部署，有时一天几次，在这种情况下，git-flow 倾向于放慢一切，在我看来，我使用 GitHub 流程。

另一件需要考虑的事情是，git-flow 并不是标准的 git，所以你可以，当我说你可以的时候，我的意思是，你会发现开发人员不知道它，然后有学习曲线，更多的机会把事情搞砸。同样如上所述，有人开发了一套脚本，使 git-flow 的使用更加容易，所以你不必记住所有的命令，它将帮助您的命令，但记住实际的流程是你的工作，我遇到过不止一次，当一个开发人员不知道它是一个修补程序还是一个功能，甚至更糟糕的是，当他们不能记住的流程和塞东西了。

至少有一个 GUI 支持 Mac 和 Windows源树的 git-flow。

现在，我更倾向于 GitHub 流，因为它简单易管理。此外，由于“经常部署早期部署”..。

希望这个能帮上忙

小开

因为所有的模型都是次优的，所以没有银弹式的工作流程，每个人都应该遵循。尽管如此，您可以根据以下几点为您的软件选择合适的模型;

生产中的多个版本-使用 Git-flow

如果您的代码在生产环境中有多个版本(即典型的软件产品，如操作系统，办公软件包，自定义应用程序等) ，你可以使用 git-flow。主要原因是你需要继续支持生产中的以前版本，同时开发下一个版本。

单版生产简单软件-使用 Github-flow

如果您的代码在任何时候都只有一个版本你可以使用 github-flow 原因是你不需要为开发人员复杂的事情。一旦开发人员完成一个功能或完成一个错误修复它立即升级为生产版。

生产中的单一版本但是非常复杂的软件-使用 Gitlab-flow

像 Facebook 和 Gmail 这样的大型软件，你可能需要介绍一下 在您的分支和主分支之间的部署分支 ，其中 CI/CD > 工具可以在进入生产环境之前运行。我的想法是对生产版本引入更多的保护，因为它被成千上万的人。