答案 0 :(得分:114)
正如GitMinutes第17集中所讨论的那样,Nicholas Zakas在他关于" GitHub workflows inside of a company"的文章中讨论过:
Git-flow是一个管理Git变更的流程,由Vincent Driessen创建,并伴有一些Git extensions来管理该流程。
git-flow背后的一般思想是拥有几个始终存在的独立分支,每个分支用于不同的目的:master
,develop
,feature
,release
和{{ 1}}。
功能或错误开发的过程在最终发布之前从一个分支流向另一个分支。部分受访者表示他们一般使用
hotfix
有些人从git-flow
开始并远离它。离开的主要原因是
git-flow
进程在连续(或接近连续)的部署模型中难以处理。
总体感觉git-flow
适用于更传统的发布模式中的产品,每隔几周发布一次,但是当您每天发布一次或更多时,此过程会大大破坏强>
简而言之:
从尽可能简单的模型开始(如GitHub流程),如果需要,可以转向更复杂的模型。
您可以根据GitHub-Flow在以下位置查看简单工作流程的有趣插图:
" A simple git branching model ",主要元素为:
git-flow
必须始终可以部署。- 通过功能分支进行的所有更改(pull-request + merge)
- 改变以避免/解决冲突;合并到
醇>master
答案 1 :(得分:69)
没有银弹工作流程,每个人都应该遵循,因为所有模型都是次优的。话虽如此,您可以根据以下几点为您的软件选择合适的型号;
生产中的多个版本 - 使用Git-flow
如果您的代码在生产中有多个版本(即典型代码) 软件产品,如操作系统,Office软件包,自定义 应用程序等)你可以使用git-flow。主要原因是你需要 在生产过程中不断支持以前的版本 开发下一个版本。
制作简单软件中的单一版本 - 使用Github-flow
如果您的代码始终只有一个版本在生产中 (即网站,网络服务等)你可以使用github-flow。主要 原因是你不需要为开发人员复杂的东西。 一旦开发人员完成一项功能或立即完成错误修复 升级到生产版。
生产中的单一版本,但非常复杂的软件 - 使用Gitlab-flow
像Facebook和Gmail这样的大型软件,您可能需要介绍一下 CI / CD>之间的分支和主分支之间的部署分支工具可以在进入生产之前运行。想法是 自使用以来,为生产版本引入了更多保护 数百万人。
答案 2 :(得分:33)
我已经使用git-flow模型超过一年了,还可以。
但这实际上取决于您的应用程序如何开发和部署。
当您的应用程序具有较慢的开发/部署流程时,它可以正常工作。
但是,例如,像GitHub一样,我们有一个具有快速开发/部署流程的应用程序,我们每天部署,有时一天几次,在这种情况下,git-flow往往会减慢我认为的一切,我使用GitHub流程。
另一件需要考虑的事情是,git-flow不是标准的git,所以你可能,当我说你的时候,我的意思是,你会发现那些不了解它的开发人员,然后就是学习曲线,更多的机会搞砸了。同样如上所述,有人开发了一组脚本,以便更轻松地使用git-flow,因此您不必记住所有命令,它将帮助您完成命令,但记住实际流程是您的工作当开发人员不知道它是修补程序或功能时,我不止一次地遇到过,或者当他们记不起流程并填充内容时,我发现了最糟糕的事情。
至少有一个GUI支持Mac和Windows的{git-flow SourceTree。
现在,由于其简单易用,我更倾向于GitHub流程。此外,由于“经常部署早期部署”......
希望这有帮助