git-flow vs github-flow的优缺点是什么？[关闭]

我们最近开始使用GitLab。

当前正在使用“集中式”工作流。

我们正在考虑移至github-flow，但我想确定一下。

git-flow vs github-flow的优缺点是什么？

正如Nicholas Zakas在GitMinutes第17集中讨论的“ 公司内部GitHub工作流 ”文章中所述：

Git流是由Vincent Driessen创建的，用于管理Git更改的过程，并伴随着一些用于管理该流的Git扩展。
背后的git流的总体思路是：有几个单独的分支总是存在的，分别用于不同的目的：master，develop，feature，release，和hotfix。
功能或错误开发过程从一个分支流向另一个分支，然后才最终发布。

一些受访者表示，他们git-flow通常使用。
一些人开始时git-flow就离开了它。

迁移的主要原因是该git-flow过程很难以连续（或近乎连续）的部署模型处理。
通常的感觉是，git-flow对于更传统的发布模型而言，产品每隔几周发布一次，效果很好，但是当您每天发布一次或多次时，此过程会大大中断。

简而言之：

从尽可能简单的模型开始（例如GitHub流程倾向于这样），并在需要时转向更复杂的模型。

您可以在以下位置看到基于GitHub-Flow的简单工作流程的有趣插图： “ 一个简单的git分支模型 ”，主要元素是：

1. master 必须始终是可部署的。
2. 通过要素分支进行的所有更改（拉动请求+合并）
3. 调整基础以避免/解决冲突；合并到master

有关实际更完整，更健壮的工作流，请参见gitworkflow（一个字）。

没有所有人都应该遵循的灵丹妙药工作流，因为所有模型都不理想。话虽如此，您可以根据以下几点为软件选择合适的模型；

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

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

生产简单软件中的单一版本-使用Github-flow

如果您的代码始终在生产中只有一个版本（即网站，Web服务等），则可以使用github-flow。主要原因是您不需要开发人员进行复杂的工作。一旦开发人员完成一项功能或完成了一个错误修正，它便会立即升级到生产版本。

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

大型软件（例如Facebook和Gmail）可能需要在分支机构和主分支机构之间引入 部署分支，然后才能运行CI / CD>工具。想法是要为生产版本引入更多保护，因为该版本已被数百万人使用。

我已经使用git-flow模型一年多了，还可以。

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

当您的应用程序的开发/部署流程缓慢时，它会很好地工作。

但是例如，像GitHub一样，我们的应用程序具有快速的开发/部署流程，我们每天部署一次，有时一天部署几次，在这种情况下，git-flow会减慢我认为的一切，因此我使用GitHub流。

要考虑的另一件事是，git-flow不是标准的git，所以您可以，当我说您可能的时候，我的意思是，您会发现不了解它的开发人员，然后就有了学习曲线，更多有机会搞砸了。同样如上所述，有人开发了一组脚本来简化git-flow的使用，因此您不必记住所有命令，它将帮助您使用这些命令，但是记住实际流程是您的工作，当开发人员不知道它是修补程序还是功能时，我遇到了不止一次，甚至在他们不记得流程并塞满东西时，甚至遇到了更糟糕的情况。

对于Mac和Windows SourceTree，至少有一个GUI支持git-flow 。

如今，由于它的简单性和易于管理性，我更倾向于GitHub flow。另外，由于“经常尽早部署” ...

希望这可以帮助