原文地址：Introduction to GitLab Flow
Git allows a wide variety of branching strategies and workflows. Because of this, many organizations end up with workflows that are too complicated, not clearly defined, or not integrated with issue tracking systems. Therefore, we propose GitLab flow as a clearly defined set of best practices. It combines feature-driven development and feature branches with issue tracking.
Git允许多种分支策略和工作流。正因为如此，许多组织的工作流过于复杂，没有明确定义，或者没有与问题跟踪系统集成。因此，我们建议将gitlab-flow作为一组明确定义的最佳实践。它将特征驱动开发和特征分支与问题跟踪结合起来
Organizations coming to Git from other version control systems frequently find it hard to develop a productive workflow. This article describes GitLab flow, which integrates the Git workflow with an issue tracking system. It offers a simple, transparent, and effective way to work with Git.
从其他版本控制系统来到Git的组织经常发现很难开发出高效的工作流。本文描述了GitLab流程，它将Git工作流与问题跟踪系统集成在一起。它提供了使用Git的简单、透明和有效的方法
When converting to Git, you have to get used to the fact that it takes three steps to share a commit with colleagues. Most version control systems have only one step: committing from the working copy to a shared server. In Git, you add files from the working copy to the staging area. After that, you commit them to your local repo. The third step is pushing to a shared remote repository. After getting used to these three steps, the next challenge is the branching model.
在转换为Git后，您必须习惯于这样一个事实：与同事共享commit需要三个步骤。大多数版本控制系统只有一个步骤：从工作副本提交到共享服务器。在Git中，您可以将工作副本中的文件添加到临时区域。在那之后，你把它们交给你的本地仓库。第三步是推送到共享的远程存储库。在习惯了这三个步骤之后，下一个挑战是分支模型
Since many organizations new to Git have no conventions for how to work with it, their repositories can quickly become messy. The biggest problem is that many long-running branches emerge that all contain part of the changes. People have a hard time figuring out which branch has the latest code, or which branch to deploy to production. Frequently, the reaction to this problem is to adopt a standardized pattern such as Git flow and GitHub flow. We think there is still room for improvement. In this document, we describe a set of practices we call GitLab flow.
由于许多刚接触Git的组织对于如何使用它没有约定，它们的存储库很快就会变得混乱。最大的问题是出现了许多长期运行的分支，这些分支都包含了部分更改。人们很难弄清楚哪个分支有最新的代码，或者哪个分支要部署到生产环境中。通常，对这个问题的反应是采用一个标准化的模式，比如git-flow和github-flow。我们认为还有改进的余地。在本文中，我们描述了一组称为gitlab-flow的实践
Git flow was one of the first proposals to use Git branches, and it has received a lot of attention. It suggests a master branch and a separate develop branch, as well as supporting branches for features, releases, and hotfixes. The development happens on the develop branch, moves to a release branch, and is finally merged into the master branch.
Git流是最早使用Git分支的提议之一，因此它受到了广泛的关注。它建议一个主（master）分支和一个单独的开发（develop）分支，以及功能（feature）、版本（release）和热修复（hotfix）的支持分支。开发发生在develop分支上，移动到release分支，最后合并到master分支
Git flow is a well-defined standard, but its complexity introduces two problems. The first problem is that developers must use the develop branch and not master. master is reserved for code that is released to production. It is a convention to call your default branch master and to mostly branch from and merge to this. Since most tools automatically use the master branch as the default, it is annoying to have to switch to another branch.
git-flow是一个定义明确的标准，但是它的复杂性带来了两个问题。第一个问题是开发人员必须使用develop分支，而不是master。master用于保留生产环境代码。通常情况下会调用master作为默认分支，并且大多数分支将合并到这里。由于大多数工具自动使用master分支作为默认分支，因此不得不切换到另一个分支是很烦人的