我们最近开始使用 GitLab。
当前使用“集中式”工作流程。
我们正在考虑迁移到 github-flow，但我想确定一下。
git-flow与github-flow的优缺点是什么？
问问题
72883 次
3 回答
142
正如Nicholas Zakas在他关于“公司内部的 GitHub 工作流”的文章中所讨论的 GitMinutes 第 17 集：
Git-flow是一个管理 Git 更改的过程，由 Vincent Driessen 创建，并附带一些用于管理该流的Git 扩展。
git-flow 背后的总体思路是拥有几个始终存在的独立分支，每个分支都有不同的用途：master、develop、feature、release和hotfix.
在最终发布之前，功能或错误开发的过程会从一个分支流向另一个分支。一些受访者表示他们
git-flow一般使用。
有些人从它开始git-flow并远离它。离开的主要原因是该
git-flow过程很难在连续（或接近连续）部署模型中处理。
一般的感觉是，git-flow对于更传统的发布模型中的产品来说效果很好，每几周发布一次，但是当你每天发布一次或更多时，这个过程就会大大中断。
简而言之：
从尽可能简单的模型开始（如 GitHub 流程往往如此），如果需要，再转向更复杂的模型。
您可以在
“一个简单的 git 分支模型”中看到一个基于GitHub-Flow的简单工作流的有趣插图，主要元素是：
master必须始终可部署。- 通过功能分支进行的所有更改（拉请求+合并）
- 变基以避免/解决冲突；合并到
master
有关实际更完整和更强大的工作流程，请参阅gitworkflow (one word)。
于 2013-08-12T13:55:32.327 回答
104
没有每个人都应该遵循的灵丹妙药工作流程，因为所有模型都不是最佳的。话虽如此，您可以根据以下几点为您的软件选择合适的型号；
生产中的多个版本 - 使用Git-flow
如果您的代码在生产中有多个版本（即典型的软件产品，如操作系统、Office 软件包、自定义应用程序等），您可以使用 git-flow。主要原因是在开发下一个版本的同时，您需要在生产中持续支持以前的版本。
生产简单软件的单一版本 - 使用Github-flow
如果您的代码始终只有一个生产版本（即网站、Web 服务等），您可以使用 github-flow。主要原因是您不需要为开发人员复杂的事情。一旦开发人员完成一项功能或完成错误修复，它就会立即升级为生产版本。
生产中的单一版本但非常复杂的软件 - 使用Gitlab-flow
像 Facebook 和 Gmail 这样的大型软件，在投入生产之前，您可能需要在您的分支和主分支之间引入 部署分支，CI/CD > 工具可以在其中运行。想法是为生产版本引入更多保护，因为它已被数百万人使用。
于 2016-03-10T11:25:34.143 回答
43
我已经使用 git-flow 模型一年多了，没问题。
但这实际上取决于您的应用程序将如何开发和部署。
当您的应用程序开发/部署流程缓慢时，它会很好地工作。
但是例如，像 GitHub 一样，我们有一个具有快速开发/部署流程的应用程序，我们每天部署，有时一天部署几次，在这种情况下，我认为 git-flow 往往会减慢一切，我使用 GitHub流动。
要考虑的另一件事是，git-flow 不是标准的 git，所以你可能会，当我说你可能会的时候，我的意思是，你会发现开发人员不知道它，然后是学习曲线，更多把事情搞砸的机会。也如上所述，有人开发了一套脚本，让 git-flow 的使用更容易，所以你不必记住所有的命令，它会帮助你使用命令，但记住实际的流程是你的工作，当开发人员不知道它是修补程序还是功能时，我不止一次遇到过，或者更糟糕的是，当他们不记得流程并将事情搞砸时。
至少有一个 GUI 支持 Mac 和 Windows SourceTree的 git-flow 。
这些天来，我更倾向于 GitHub flow，因为它简单且易于管理。此外，由于“经常部署早期部署”......
希望这可以帮助
于 2013-09-25T21:51:38.003 回答