Git 是一个强大的版本控制系统，被开发人员广泛用于管理和跟踪项目中的更改。使用Git 的关键方面之一是选择正确的工作流程来简化协作并维护干净的存储库历史记录。本文探讨了三种流行的Git 工作流程：Git Flow、GitHub Flow 和GitLab Flow，并提供了为您的项目选择正确工作流程的见解。

不同类型的 Git 工作流程

1.Git流程

Git Flow 由Vincent Driessen 撰写博客成功的Git 分支模型nvie.com

我成长于

文森特·德里森

分支模型如下所示：

git流

主要分支机构包括：

master：包含生产代码的主分支。开发：在升级到主分支之前合并所有功能和错误修复的开发分支。 feature：为开发个别功能而创建的临时分支。一旦功能完成，这些临时分支就会合并到分支中。 release：为下一个版本做准备而创建的分支。在与master 合并之前可以进行错误修复和最终调整。修补程序：为修复生产代码中的关键错误而创建的分支。这些分支直接合并到master中并进行开发。使用git flow 的日常步骤：

创建功能分支来开发新功能。在功能分支中完成新功能的开发后，将它们合并回开发分支。从您的开发分支创建一个发布分支。当你完成release分支版本的微调和bug修复后，如果你发现master分支的代码有重要的bug，你应该将release分支合并到master分支。如果您需要立即修复并发布，您应该从master 分支创建一个修补程序分支并修复该分支中的问题。完成并测试后，将更改合并回主分支并创建发布标签。使用Git Flow 工具完成Git Flow 中的关键分支管理步骤。

# 从开发分支创建一个名为feature/FEATHRE_NAME 的新分支git flow feature start FEATHRE_NAME# 完成feature/FEATHRE_NAME 分支功能的开发，并将其合并到开发分支# 从git flow featurefinish FEATHRE_NAME# 开发分支0 分支git 创建release/1.0 flow release start 1.0.0# 一旦你完成了功能的修复和测试，你需要将release分支合并到master和development分支。 git flow releasefinish 1.0.0# 从master 创建一个Hotfix 分支。分支git flow hotfix start 1.0.0# 完成Hotfix 分支# 合并hotfix 分支到master，开发分支#，并创建发布标签git flow hotfixfinish 1.0.0 2. GitHub Flow

GitHub Flow 作者：Scott Chacon

斯科特·查康

所提出的简单轻量级工作流程是用于团队协作的简单有效的Git 工作流程，突出了工作流程的流畅简洁。该工作流程只有一个用于生产的主分支（通常称为“master”或“main”），所有新功能、错误修复等都放置在该主分支之上创建的新分支中。

以下是使用Github Flow 的基本步骤：

从Master/Main 分支创建新分支当您准备好开始新的工作项（新功能、错误修复或其他更改）时，您需要从Master/Main 分支创建新分支。

git checkout master # 或main git pull git checkout -b my-new-feature 添加到新分支提交适用于新分支并提交更改。

git add . git commit -m ‘我的新功能’ 发布新分支到远程仓库在这一步中，您将把本地新分支推送到远程仓库。

git Push -u Origin my-new-feature 将向master/main 分支发送拉取请求。当您准备好将新功能合并到主/主分支时，您可以在远程存储库中创建拉取请求并进行代码审查。你可以在上面运行。

拉取请求评论并合并评论代码。通过审核后，即可将新分支合并到master/主分支中。为此，请选择远程存储库中的“合并拉取请求”按钮。

将部署代码合并到master/main 分支后，您就可以将此代码部署到生产环境中。

在Github Flow 工作流程中，master/主分支中的代码必须始终处于可部署状态。

流程非常简单，重点关注持续部署和持续集成流程。此过程使部署过程自动化，并要求新代码在合并到master/main 分支时自动部署。

3.GitLab流程

GitLab Flow 是一种灵活的工作流程模式，旨在适应从简单到复杂的各种开发项目。它是Git 和Github 流程的改进和扩展，建立在它的基础上，并添加了环境分支的概念，主要是为了满足持续交付和持续部署的需求。

GitLab 流程可以简单地理解如下。

GitLab Flow=功能分支工作流+ 环境分支GitLab Flow 的核心包括以下几个方面：

主分支始终稳定：主分支（通常称为main 或master）始终稳定。所有成品都将从该分支发布。功能分支：与GitHub Flow 类似，新功能在功能分支中开发。完成后，通过合并请求(MR) 将其合并回主分支。环境分支：用于部署到不同的环境（生产、预生产等）。这有点类似于Git Flow 的开发和发布分支，但提供了更多的灵活性和清晰度。使用标签发布：使用标签来识别生产中的发布版本。下面是GitLab Flow 的流程图。

GitLab Flow 工作流程

在Gitlab 流程中，主分支（main 或master）和环境分支通常设置为受保护，您无法向它们提交开发。使用Gitlab流程时，必须遵循上游优先的基本原则。也就是说，只有一个master 分支，并且该分支位于所有其他分支的上游。

例如，在上图中，“开发环境”分支是master，“预发布环境”分支是预生产，“生产环境”分支是生产。代码更改必须从“上游”到“下游”进行。

使用master –merge– pre-making –merge–product Gitlab 流程的一般步骤是：

从主分支（main 或master）创建一个功能函数分支。功能分支开发完成后，将功能分支合并到主分支中，并通过合并到主分支发起的MR请求的代码审查。分支（主或主） 主分支（主或主） 持续集成和持续部署通常在测试通过后合并到生产中。分支（如果有预生产分支，先合并到预生产分支，然后从预生产分支合并到生产分支），最后在生产分支上发布标签

选择正确的 Git 工作流程

三个工作流程。 Git Flow、Github Flow 和Gitlab Flow 都基于敏捷软件开发方法论特征驱动开发（FDD），其中从主分支（例如main 或master）创建新的功能分支来开发特定功能。编码、单元测试和其他工作在功能分支中执行。当与功能驱动开发（FDD）结合时，Git 流程最复杂，Github 流程最简单，Gitlab 流程最灵活。

每个流程都有优点和局限性，选择正确的Git 工作流程取决于团队规模、项目特征、协作方式和发布频率等因素。不存在适合所有项目的单一“正确”工作流程。在功能驱动开发(FDD) 的背景下，以下是一些根据您的情况选择最佳工作流程的一般准则。

对于多版本维护和定时发布：如果你的项目需要同时维护多个版本，并且版本发布周期相对固定，Git Flow 可能是更好的选择。对于快速迭代和持续部署：如果您的项目寻求快速迭代和持续部署（敏捷开发），如果您的项目需要灵活性和稳定性：对于需要灵活性和稳定性的项目：等等）。测试、在预生产和生产环境之间可靠地传输代码（每次都进行测试），同时提供部署灵活性（即何时以及如何根据需要将更改部署到另一个环境）GitLab Flow 可能是最佳选择。最好的选择。