当前位置：首页 > article >正文

GitFlow工作流

article 2024/12/26 8:30:37

GitFlow 是一种基于 Git 的软件开发迭代模型和源代码管理的行为规范，旨在通过定义严格的分支模型来围绕项目发布组织工作流程。它帮助团队提高协作效率，并减少开发过程中的混乱。

在这里插入图片描述

master 分支：存储了发布版本的历史，每个版本都通过tag标记（如 git tag -a v0.1），确保每一个正式发布的版本都有一个唯一的标识。该分支应始终保持稳定，只包含已经经过全面测试并准备部署到生产环境的代码。
develop 分支：作为集成分支，用于整合各个功能分支的功能。它是所有新特性和改进的集合地，方便为 master 分支上的提交分配版本号。此分支反映了下一次发布的所有改动，但尚未准备好进入生产环境。

创建：每个新功能的开发应在从 develop 分支派生出的新 feature 分支上进行。这使得不同开发者可以独立工作而不互相干扰，避免未完成的功能影响主干的稳定性。
命名约定：通常以 feature/ 开头，后接描述性的名称（如 feature/user-authentication）。
合并：完成功能开发后，应将 feature 分支合并回 develop 分支，但不直接与 master 分支交互。为了保持历史记录清晰，建议使用 --no-ff 参数执行非快进式合并。

创建：当一系列功能完成并满足发布的条件时，这些功能会被合并到 develop 分支，然后从 develop 创建一个 release 分支。此时应该确定一个明确的版本号。
命名约定：一般以 release/ 开头，后接版本号（如 release/1.2.0）。
操作：release 分支主要用于准备即将发布的版本，在此期间可以进行最后的测试、修复bug以及编写发布文档等工作。在此阶段，不允许添加新的功能，仅限于必要的修复和优化。
合并：发布完成后，release 分支会合并到 master 和 develop 分支，并打上版本标签，以标记此次发布的结束。合并回 develop 分支很重要，因为在 release 分支中已经提交的更新需要在后面的新功能中也是可用的。

创建：用于快速修复生产环境中出现的问题。维护分支直接从 master 分支派生，以便尽快解决问题。这是唯一一个可以从 master 分支直接派生的分支类型。
命名约定：一般以 hotfix/ 开头，后接描述性的名称或版本号（如 hotfix/urgent-bugfix 或 hotfix/v1.0.1）。
合并：修复完成后，维护分支需要同时合并回 master 和 develop 分支，保证所有后续开发也能享受到该修复带来的好处。合并后应立即给 master 分支打上新版本标签。

为了简化上述分支的操作，可以使用 git flow 命令行工具。以下是几个常用的命令：

初始化 GitFlow 配置：git flow init
- 按照提示设置默认分支名等参数。
创建新的功能分支：git flow feature start <name>
- 例如：git flow feature start user-authentication
完成功能分支：git flow feature finish <name>
- 自动合并回 develop 分支，并删除本地及远程的功能分支。
开始一个新的发布周期：git flow release start <version>
- 例如：git flow release start 1.2.0
完成发布周期：git flow release finish <version>
- 自动合并回 master 和 develop 分支，打上版本标签，并删除发布分支。
创建并完成紧急修复分支：git flow hotfix start <version> 和 git flow hotfix finish <version>
- 例如：git flow hotfix start v1.0.1

持续集成/持续交付（CI/CD）：GitFlow 工作流非常适合与 CI/CD 系统结合使用。每当有新的提交推送到 develop 或 release 分支时，CI/CD 管道可以自动触发构建、测试和部署任务。对于 master 分支，则可以在每次新版本发布时触发更严格的检查和自动化部署流程。
多团队协作：在一个大型项目中，可能有多个团队负责不同的模块或组件。GitFlow 提供了一种结构化的方式来协调这些团队之间的合作，确保各自的工作不会相互冲突，同时也便于追踪每个团队的进展。