git-flow与github-flow的优点和缺点是什么？
我们最近开始使用GitLab.
目前正在使用"集中式"工作流程.
我们正在考虑转向github-flow,但我想确定一下.
git-flow与github-flow的优点和缺点是什么？
Von*_*onC 122
正如GitMinutes第17集中所讨论的那样,Nicholas Zakas在他关于" 公司内部的GitHub工作流程 "的文章中进行了讨论:
Git-flow是一个管理Git变更的过程,由Vincent Driessen创建并附带一些Git扩展来管理该流程.
背后的git流的总体思路是:有几个单独的分支总是存在的,分别用于不同的目的:master,develop,feature,release,和hotfix.
功能或错误开发的过程在最终发布之前从一个分支流向另一个分支.一些受访者表示他们
git-flow一般使用.
一些人开始git-flow并离开它.离开的主要原因是该
git-flow过程很难在连续(或接近连续)的部署模型中处理.
一般的感觉是,git-flow对于更传统的发布模型中的产品来说效果很好,每隔几周发布一次,但是当您每天发布一次或更多时,这个过程会大大破坏.
简而言之:
从尽可能简单的模型开始(如GitHub流程),如果需要,可以转向更复杂的模型.
您可以看到一个简单的工作流程的有趣插图,基于GitHub-Flow:
" 一个简单的git分支模型 ",主要元素是:
master必须始终可以部署.- 通过功能分支进行的所有更改(pull-request + merge)
- 改变以避免/解决冲突; 合并到
master
- 变基以避免冲突？？？ (3认同)
Gay*_*age 74
没有银弹工作流程,每个人都应该遵循,因为所有模型都是次优的.话虽如此,您可以根据以下几点为您的软件选择合适的型号;
生产中的多个版本 - 使用Git-flow
如果您的代码在生产中有多个版本(即典型的软件产品,如操作系统,Office软件包,自定义应用程序等),您可以使用git-flow.主要原因是您需要在开发下一个版本的同时不断支持以前的生产版本.
生产简单软件中的单一版本 - 使用Github-flow
如果您的代码在任何时候都只有一个版本(即网站,Web服务等),您可以使用github-flow.主要原因是您不需要为开发人员复杂的事情.一旦开发人员完成功能或完成错误修复,它立即升级到生产版本.
生产中的单一版本,但非常复杂的软件 - 使用Gitlab-flow
像Facebook和Gmail这样的大型软件,您可能需要在分支和主分支之间引入 部署分支,其中CI/CD>工具可以在生产之前运行.自数百万人使用以来,想法是为生产版本引入更多保护.
- 只需将"Gitdmz-flow"/"Git DMZ Flow"添加到列表中:https://gist.github.com/djspiewak/9f2f91085607a4859a66 (6认同)
- @GayanPathirage实际上并非如此.1.主人的"经典"GitFlow标签.Hotfix分支仅供您对最新的生产版本(来自master)进行修复.2."发布分支"在Gitflow中意味着其他东西,它实际上是预发布预览分支(从开发分支分支,并且旨在在真正发布时合并为主).3.你所指的是GitFlow中所谓的"支持分支"(这是我不喜欢GitFlow的一个原因:非常规术语).然而,它仍然是实验流程(所以你不会在大多数Gitflow推出中看到它) (5认同)
- Git DMZ 流程更类似于 Gitflow，DMZ 分支类似于开发分支。所以我觉得没什么特别的。 (2认同)
- 据我了解，Git-Flow不适用于多生产版本。该修补程序策略假定您只有一个生产版本，并且您在相应的发行分支上进行了修补（然后将其合并回developer分支）。似乎无法解决如何修复多个生产分支中存在的一个错误。 (2认同)
Die*_*nes 36
我已经使用git-flow模型超过一年了,还可以.
但这实际上取决于您的应用程序如何开发和部署.
当您的应用程序具有缓慢的开发/部署流程时,它可以很好地工作.
但是,例如,像GitHub一样,我们有一个具有快速开发/部署流程的应用程序,我们每天部署,有时一天几次,在这种情况下,git-flow往往会减慢我认为的一切,我使用GitHub流.
另外要考虑的是,git-flow不是标准的git,所以你可能,当我说你可能,我的意思是,你会找到不了解它的开发人员,然后有学习曲线,更多把事搞砸的机会.同样如上所述,有人开发了一组脚本,以便更轻松地使用git-flow,因此您不必记住所有命令,它将帮助您完成命令,但记住实际流程是您的工作当开发人员不知道它是否是一个修补程序或功能时,我不止一次地遇到过,或者当他们无法记住流程并填充内容时,我发现了最糟糕的情况.
至少有一个GUI支持Mac和Windows SourceTree的 git-flow .
这些天,由于其简单易用,我更倾向于GitHub流程.另外,由于"经常部署早期部署"......
希望这可以帮助
- GitHub流程在Git-Flow中.想想你是否需要持续集成和持续部署,你可以使用develop分支尽可能多地运行.每个功能都从开发分支分支.除非您具有复杂的部署模型,否则您可能不需要主分支或发布分支.(例如,您的1.1版本在某个客户端上运行,您的1.2在另一个客户端上运行,目前您为新客户端开发1.3)所有3个客户端将要求修复错误并更改其各自的版本. (2认同)
- @LuisGouveia 实际上，自从你的问题和我上面的回复以来，我遇到了一个 git-flow 可以完美工作的项目，并且我拥有该项目的所有权。这个想法是结合使用 `git flow release...` 和 github actions 来部署应用程序。在我最初的回复中，我提到我们一天发布多次，这在使用 git-flow 时导致了问题。我认为 git-flow 在这个项目中运行良好的原因是因为我们有一个预定义的发布周期，这是使用 git-flow 的主要卖点之一。 (2认同)
| 归档时间： |
|
| 查看次数： |
48809 次 |
| 最近记录： |