git-flow 与 github-flow 的优缺点是什么? [英] What are the pros and cons of git-flow vs github-flow?

问题描述

我们最近开始使用 GitLab.

目前使用集中式"工作流程.

我们正在考虑迁移到 github-flow，但我想确定一下.

git-flow vs github-flow?

解决方案

正如 GitMinutes 第 17 集所述，作者 Nicholas Zakas 在他关于 的文章中公司内部的 GitHub 工作流程":

<块引用>

Git-flow 是在 Git 中管理变更的过程它由 Vincent Driessen 创建，并附带一些用于管理该流程的 Git 扩展.
git-flow 背后的总体思路是拥有几个始终存在的独立分支，每个分支都有不同的用途:master、develop、feature、release 和 hotfix.
在最终发布之前，功能或错误开发过程会从一个分支流向另一个分支.

一些受访者表示他们通常使用 git-flow.
有些人从 git-flow 开始，然后离开了它.

离开的主要原因是 git-flow 过程在连续(或接近连续)部署模型中难以处理.
总体感觉是 git-flow 适用于更传统的发布模型中的产品，其中发布每隔几周完成一次，但是当您发布时，这个过程会大大中断一天一次或更多次.

简而言之:

从尽可能简单的模型开始(如 GitHub 流程往往如此)，如果需要，再转向更复杂的模型.

<小时>

您可以看到一个基于 简单工作流程的有趣插图"noreferrer">GitHub-Flow at:
一个简单的 git 分支模型"，主要元素是:

<块引用>

1. master 必须始终可部署.
2. 通过功能分支进行的所有更改(拉取请求 + 合并)
3. rebase 以避免/解决冲突；合并到 master

<小时>

如需实际更完整、更强大的工作流程，请参阅 gitworkflow(一个字).

We have recently started to use GitLab.

Currently using a "centralized" workflow.

We are considering moving to the github-flow but I want to make sure.

What are the pros and cons of git-flow vs github-flow?

解决方案

As discussed in GitMinutes episode 17, by Nicholas Zakas in his article on "GitHub workflows inside of a company":

Git-flow is a process for managing changes in Git that was created by Vincent Driessen and accompanied by some Git extensions for managing that flow.
The general idea behind git-flow is to have several separate branches that always exist, each for a different purpose: master, develop, feature, release, and hotfix.
The process of feature or bug development flows from one branch into another before it’s finally released.

Some of the respondents indicated that they use git-flow in general.
Some started out with git-flow and moved away from it.

The primary reason for moving away is that the git-flow process is hard to deal with in a continuous (or near-continuous) deployment model.
The general feeling is that git-flow works well for products in a more traditional release model, where releases are done once every few weeks, but that this process breaks down considerably when you’re releasing once a day or more.

In short:

Start with a model as simple as possible (like GitHub flow tends to be), and move towards a more complex model if you need to.

---

You can see an interesting illustration of a simple workflow, based on GitHub-Flow at:
"A simple git branching model", with the main elements being:

1. master must always be deployable.
2. all changes made through feature branches (pull-request + merge)
3. rebase to avoid/resolve conflicts; merge in to master

---

For an actual more complete and robust workflow, see gitworkflow (one word).

这篇关于git-flow 与 github-flow 的优缺点是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！