简单介绍一下 Git 工作流

Git 作为一个强大的版本控制系统，成为多人协作开发的核心工具。

为了保障团队协作的顺畅和高效，必须遵循一套规范的工作流程。

1. Git flow

Git flow 实际是 Git 工作流程的抽象概念。明确规定了应如何创建不同类型的分支（如主分支、功能分支、发布分支等），以及这些分支之间应如何合并，从而确保团队能够协同一致，快速响应变化，同时保持代码库的清晰与稳定。

Git flow 是最早诞生，并且使用最广泛的工作流程。

首先，我们的项目中存在两个长期分支，主分支 master（main） 和 开发分支 develop。

1、master 分支是项目中最稳定可靠的分支。代表项目的官方发布历史，包含了所有已经发布到生产环境的版本。任何时候从该分支拉取的代码，都应该是可以直接部署生产环境的代码状态。

2、develop 分支上项目的主要开发分支，包含了所有最新的开发进度。所有的新功能开发、bug 修复以及其他非发布相关的代码更改，都应该合并到这个分支。

其次，项目存在三个短期分支。功能分支 feature、修复分支 hotfix、发布分支 release。

1、feature 分支是用于开发新功能的分支，它从 develop 分支拉取最新代码，并在其上实现新功能。开发完成并通过测试后，将其合并回 develop 分支，不再需要可以删除。

2、hotfix 分支用于修复 master 分支上的紧急问题，这些问题通常无法等到下一个版本发布，比较紧急。从 master 分支上拉取最新代码，进行必要的修复。完成后先合并回 master 分支，及时修复功能，然后合并回 develop 分支，保持开发分支和主分支的同步。

3、release 分支用于准备和测试即将发布的版本。它从 develop 分支拉取最新代码，并进行必要的发布前准备，如版本号更新、文档更新等。完成后，将发布分支合并回 master 分支，并打上相应的标签（tag）用以标识发布版本。

Git Flow

优点是直观、清晰、方便控制。

缺点是比较复杂，需要同时维护 master 分支和 develop 分支。

2. Github flow

Github flow 是 Git flow 的简化版，更适合持续集成/部署的软化开发方式。

GitHub flow 强调简单、快速和灵活的分支和合并策略。

大致流程：

1、从 master 上创建新分支，用于新需求、功能、修复等，分支名称用来描述目的或功能。

2、在新分支上进行开发，编写代码、运行测试。

3、发起 PR（Pull Request），当开发完成或代码检查时，向 master 分支发起一个 PR，告诉别人代码已准备好审查。

4、代码审查与讨论，进行修改完善代码。

5、合并 PR，将新分支代码合并到 master 上。合并之前进行测试，确保没有其他问题。

6、部署，将新的代码部署到生产环境或测试环境。部署完成后，可以将新分支删除。

在 Github flow 中，master 始终包含可部署的代码。因此在每次合并回 master 时，都需要充分的测试和检测，保证不会对生产环境造成影响。

整个过程都是线性的，简化了分支和合并，适合于快速迭代和持续开发的模式。

3. Gitlab flow

Gitlab flow 可以视为 Git flow 和Github flow 的综合。

大致流程：

1、创建分支，根据开发需求 or 修复任务，从 master/main 上创建特性分支。

2、开发，在每一个新分支上进行开发，编码、测试、重构等操作。

3、MR，当开发完成后，发起一个合并请求（Merge Request），将代码更改合并到主分支。

4、代码审查。

5、合并到主分支，当代码审查和测试均通过时，将开发分支代码合并到主分支。

6、部署发布，将新功能或修复推送到生产环境或测试环境。