git-flow vs github-flow有什么优点和缺点？
我们最近开始使用GitLab。
目前使用“集中”工作stream程。
我们正在考虑转向github-flow，但我想确保。
git-flow vs github-flow有什么优点和缺点？
正如GitMinutes第17集中Nicholas Zakas在其关于“ 公司内部GitHub工作stream程 ”的文章中所讨论的那样：
Git-flow是一个pipe理由Vincent Driessen创build的Git中的更改的过程，并伴随着pipe理该stream程的一些Git扩展 。
git-flow背后的一般理念是有几个独立的分支，每个分支都有不同的目的：master，develop，feature，release和hotfix。
function或错误开发的过程在最终发布之前从一个分支stream入另一个分支。一些受访者表示他们普遍使用
git-flow。
有些从git-flow开始，离开它。迁移的主要原因是在连续（或接近连续）的部署模型中，
git-flowstream程很难处理。
一般的感觉是，git-flow在更传统的发布模式下运行良好，每几个星期发布一次，但是当你每天发布一次或更多的时候，这个过程就会相当严重 。
简而言之：
从尽可能简单的模型开始（比如GitHubstream程），如果需要的话，可以转向更复杂的模型。
你可以看到一个简单的工作stream程的有趣的例子，基于GitHub-Flow ：
“ 一个简单的git分支模型 ”，主要内容是：
master必须始终可以部署。- 通过function分支所做的所有更改（拉取请求+合并）
- 避免/解决冲突 合并到
master
没有银弹的工作stream程，每个人都应该遵循，因为所有的模型都是次优的。 话虽如此，您可以根据以下几点为您的软件select合适的型号;
生产中的多个版本 – 使用Git-flow
如果您的代码在生产中有多个版本（即典型的软件产品，如操作系统，办公软件包，自定义应用程序等），您可以使用git-flow。 主要原因是在开发下一个版本时需要不断支持以前的版本。
在生产简单的软件单一版本 – 使用Githubstream
如果你的代码在任何时候只有一个版本在生产（即网站，Web服务等），你可以使用Github-Flow。 主要原因是你不需要为开发者复杂的事情。 一旦开发人员完成function或完成错误修复，立即将其升级到生产版本。
生产中的单一版本，但非常复杂的软件 – 使用Gitlabstream程
像Facebook和Gmail这样的大型软件，您可能需要在CI / CD>工具可以运行的分支和主分支之间引入部署分支 ，然后投入生产。 想法是从数百万人使用以来，为生产版本引入更多的保护。
我一直在使用git-flow模型一年多了。
但是，这取决于您的应用程序如何开发和部署。
当你有一个缓慢的开发/部署stream程的应用程序时，它运行良好。
但是例如，像GitHub，我们有一个快速开发/部署stream程的应用程序，我们每天部署，有时候每天部署数次，在这种情况下，git-flow往往会放慢我的观点，我使用GitHubstream。
另一件要考虑的事情是，git-flow不是标准的git，所以你可能，当我说你可能的时候，我的意思是，你会发现开发人员不知道它，然后是学习曲线，更多机会搞砸了。 也正如上面提到的，有人开发了一套脚本来使git-flow的使用更加容易，所以你不必记住所有的命令，它会帮助你的命令，但记住实际的stream程是你的工作，当开发者不知道它是一个修补程序还是function时，我碰到过不止一次，甚至当他们不记得stream量和东西时，甚至是最糟糕的。
至less有一个GUI支持Mac和Windows SourceTree的 git-flow。
这些天，我更倾向于GitHubstream程，由于其简单和易于pipe理。 另外，由于“部署早期部署”…
希望这可以帮助
