GitHub Flow 和 GitLab Flow 有什么区别? [英] What is the difference between GitHub Flow and GitLab Flow?
问题描述
最近我在 GIT 中发现了工作流的三个概念:GitFlow、GitHub Flow 和 GitLab Flow.我已经阅读了关于它的
我们有一个主分支作为生产分支.此外，我们还有一个开发分支，每个开发人员都可以在其中合并他的功能.有时我们会创建一个发布分支来在生产中部署我们的功能.如果我们在发布分支中有错误，请修复它并将更改拉入开发分支.如果我们在生产中遇到严重错误，请创建新的修补程序分支，修复错误并将分支与生产(主)合并并开发分支.
如果我们很少发布我们的工作结果，这种方法很有效.(可能每 2 周一次).
GitHub 流
我们有一个主分支作为生产分支.我们(作为开发人员)可以创建用于添加新功能或修复错误的分支，并将它们与生产(主)分支合并.听起来很简单.这种方法适合在一天内多次部署生产分支的极端编程.
GitLab 流程
我见过一些新术语，例如预生产、生产、发布(稳定)分支和暂存环境、预生产环境、生产环境.他们之间有什么关系?
我是这样理解的:如果我们需要添加新功能，我们会从主分支部署一个预生产分支.完成该功能后，我们从预生产分支部署一个生产分支.预生产分支是中间阶段.然后主分支从生产分支中拉取所有更改.
如果我们想查看每个单独的功能，这种方法很好；我们只需在分支中签出我们需要查看的内容.
但是如果我们需要展示我们的工作，我们会尽可能晚地创建一个带有标签的发布分支.如果稍后我们修复主分支中的错误，我们需要将它们挑选到最后一个发布分支.最后，我们有带有标签的发布分支，可以帮助我们在版本之间移动.
我的理解正确吗?
pull和cherry-pick有什么区别?
GitLab Flow 建议也使用 master 和 feature 分支.一旦功能完成，我们将其合并回 master 分支.这部分看起来与 GitHub Flow 中的相同.
那么我的理解是，他们为我们提供了 2 个选项，具体取决于它是 SAAS 应用程序还是移动应用程序(可以向全世界发布).
如果这是 SAAS 应用，我们会使用环境分支，例如pre-production 和 production.当我们准备好部署我们的应用程序时，这些分支是从 master 创建的.每个环境有不同的分支允许我们设置 CI/CD 工具来自动部署对这些分支的提交.如果有关键问题，我们会在 feature 或 master 分支中修复它，然后将其合并到 environment 分支.
至于可以向世界发布的应用程序(例如移动或桌面应用程序)，我的理解是他们建议通过使用 release 分支而不是环境分支来使用不同的模型.我们仍然在 feature 分支中完成所有工作，并在完成后将它们合并回 master 分支.然后，当我们确保 master 分支足够稳定时，即我们已经执行了所有测试和错误修复，我们创建 release 分支并发布我们的软件.如果有一个关键问题，我们首先在 master 分支中修复它，然后挑选一个修复到 release 分支.
Recently I've found the three concepts of a workflow in GIT: GitFlow, GitHub Flow and GitLab Flow. I've read the nice articles about it but I don't understand GitLab Flow very well. Maybe because I'm not a native speaker :)
Briefly.
GitFlow
We've a master branch as a production branch. Also we have a develop branch where every developer merges his features. Sometimes we create a release branch to deploy our features in production. If we have a bug in the release branch, fix it and pull changes into the develop branch. If we have a critical bug in production, create new hotfix-branch, fix the bug and merge branch with production (master) and develop branches.
This approach works well if we seldom publish results of our work. (Maybe once every 2 weeks).
GitHub Flow
We have a master branch as a production branch. And we (as developers) can create branches for adding new features or fixing bugs and merge them with production (master) branch. It sounds very simple. This approach fits for extreme programming where the production branch is deployed several times in a day.
GitLab Flow
I've seen new terms like a pre-production, a production, a release (stable) branch and a staging environment, a pre-production environment, a production environment. What relationships do they have between them?
I understand it this way: If we need to add a new feature we deploy a pre-production branch from the master branch. When we have finished the feature, we deploy a production branch from the pre-production branch. A pre-production branch is the intermediate stage. And then the master branch pulls all changes from the production branch.
The approach is good if we want to see each separate feature; we just checkout in the branch what we need to look at.
But if we need to show our work we create a release branch with a tag as late as possible. If later we fix bugs in the master branch we need to cherry-pick them to the last release branch. At the end we have the release branch with tags that can help us to move between versions.
Is my understanding correct?
What is the difference between pull and cherry-pick?
GitLab Flow proposes to use master and feature branches too. Once feature is done we merge it back to master branch. This part looks the same as in GitHub Flow.
Then my understanding is that they give us 2 options on how to do it depending on whether it's SAAS app or mobile app (which can be release out to the world).
If this is SAAS app we use environment branches e.g. pre-production and production. These branches are created off the master when we are ready to deploy our application. Having different branches per environment allow us to setup CI/CD tool to automatically deploy on commits made to these branches. If there is a critical issue we fix it in feature or master branch and then merge it to environment branches.
As for applications which can be released out to the world (e.g. mobile or desktop apps) my understanding is that they propose to use different model by using release branches instead of environment branches. We still do all work in feature branches and merge them back to master branch upon completion. Then when we make sure that master branch is stable enough i.e. we have already performed all testing and bug-fixing we create release branch and release our software. If there is a critical issue we first fix it in master branch and cherry-pick a fix to release branch.
这篇关于GitHub Flow 和 GitLab Flow 有什么区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
