本文使用AI翻译，原文：# Gitflow workflow
Gitflow 工作流
Gitflow 工作流是一种传统的 Git 工作流，最初是一种用于管理 Git 分支的创新性策略。但如今，它的受欢迎程度已经下降， trunk-based 工作流更受青睐，后者现在被认为是现代持续软件开发和 DevOps 实践的最佳实践。此外，Gitflow 在与 CI/CD 结合使用时也可能面临挑战。本篇文章将详细介绍 Gitflow，主要出于历史回顾的目的。
什么是 Gitflow？
Gitflow 是一种替代 Git 分支模型，它涉及到功能分支和多个主分支的使用。它最初由 Vincent Driessen 在 nvie 上发布并流行起来。与基于主干的开发相比，Gitflow 有更多、存在时间更长的分支以及更大的提交。在这种模型下，开发人员会创建一个功能分支，并将其合并到主干分支的操作推迟到功能完成之后。这些长期存在的功能分支在合并时需要更多的协作，而且偏离主干分支的风险更高，还可能引入相互冲突的更新。
Gitflow 可用于有预定发布周期的项目，也适用于持续交付这一 DevOps 最佳实践。除了功能分支工作流所需的概念和命令外，该工作流没有增加任何新的概念或命令。相反，它为不同的分支分配了非常具体的角色，并定义了它们应该如何以及何时进行交互。除了 “功能（feature）” 分支外，它还使用单独的分支来准备、维护和记录发布版本。当然，你也可以充分利用功能分支工作流的所有优势：拉取请求、隔离实验以及更高效的协作。
它是如何工作的？
主分支（Main）和开发分支（Develop）
这个工作流不是使用单一的 “主（main）” 分支，而是使用两个分支来记录项目的历史。“主（main）” 分支存储官方的发布历史，“开发（develop）” 分支则作为功能的集成分支。将 “主（main）” 分支中的所有提交都标记上版本号是很方便的做法。
第一步是在默认的 “主（main）” 分支之外补充一个 “开发（develop）” 分支。一种简单的方法是，由一名开发人员在本地创建一个空的 “开发（develop）” 分支，然后将其推送到服务器：
git branch develop
git push -u origin develop
这个分支将包含项目的完整历史，而 “主（main）” 分支将包含一个精简版本。其他开发人员现在应该克隆中央仓库，并为 “开发（develop）” 分支创建一个跟踪分支。
当使用 git-flow 扩展库时，在现有仓库上执行 “git flow init” 会创建 “开发（develop）” 分支：
$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
$ git branch
* develop
main
功能分支（Feature branches）
每个新功能都应该位于自己的分支中，这个分支可以被推送到中央仓库以进行备份或协作。但是，“功能（feature）” 分支不是从 “主（main）” 分支分出，而是以 “开发（develop）” 分支作为其父分支。当一个功能完成后，它会被合并回 “开发（develop）” 分支。功能分支绝不应该直接与 “主（main）” 分支进行交互。
需要注意的是，“功能（feature）” 分支与 “开发（develop）” 分支相结合，实际上就是功能分支工作流。但 Gitflow 工作流并未止步于此。
“功能（feature）” 分支通常是从最新的 “开发（develop）” 分支创建出来的。
创建功能分支
不使用 git-flow 扩展时：
git checkout develop
git checkout -b feature_branch
使用 git-flow 扩展时：
git flow feature start feature_branch
继续你的工作，并像往常一样使用 Git。
完成功能分支
当你完成功能的开发工作后，下一步是将 “功能分支（feature_branch）” 合并到 “开发（develop）” 分支。
不使用 git-flow 扩展时：
git checkout develop
git merge feature_branch
使用 git-flow 扩展时：
git flow feature finish feature_branch
发布分支（Release branches）
一旦 “开发（develop）” 分支获得了足够多可用于发布的功能（或者预定的发布日期即将到来），你就可以从 “开发（develop）” 分支分出一个 “发布（release）” 分支。创建这个分支意味着下一个发布周期的开始，所以在这之后不能再添加新功能 —— 只能进行错误修复、生成文档以及其他与发布相关的任务。一旦准备好发布，“发布（release）” 分支会被合并到 “主（main）” 分支，并标记上版本号。此外，它还应该被合并回 “开发（develop）” 分支，因为自从发布工作开始以来，“开发（develop）” 分支可能已经有了新的进展。
使用专门的分支来准备发布版本，使得一个团队可以完善当前的发布版本，而另一个团队可以继续为下一个发布版本开发功能。它还能创建定义清晰的开发阶段（例如，很容易说 “这周我们正在准备 4.0 版本”，并且能在仓库的结构中实际体现出来）。
创建 “发布（release）” 分支也是一个简单的分支操作。和 “功能（feature）” 分支一样，“发布（release）” 分支也是基于 “开发（develop）” 分支创建的。可以通过以下方法创建一个新的 “发布（release）” 分支。
不使用 git-flow 扩展时：
git checkout develop
git checkout -b release/0.1.0
使用 git-flow 扩展时：
$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'
一旦发布版本准备好可以发布，它将被合并到 “主（main）” 分支和 “开发（develop）” 分支，然后 “发布（release）” 分支将被删除。将其合并回 “开发（develop）” 分支是很重要的，因为 “发布（release）” 分支中可能添加了重要的更新，这些更新需要让新功能能够使用。如果你的组织强调代码审查，那么这里将是一个理想的拉取请求的地方。
要完成一个 “发布（release）” 分支，可以使用以下方法：
不使用 git-flow 扩展时：
git checkout main
git merge release/0.1.0
使用 git-flow 扩展时：
git flow release finish '0.1.0'
热修复分支（Hotfix branches）
维护分支或 “热修复（hotfix）” 分支用于快速修补生产环境中的发布版本。“热修复（hotfix）” 分支与 “发布（release）” 分支和 “功能（feature）” 分支非常相似，但它们是基于 “主（main）” 分支而不是 “开发（develop）” 分支创建的。这是唯一应该直接从 “主（main）” 分支分出的分支。一旦修复完成，它应该被合并到 “主（main）” 分支和 “开发（develop）” 分支（或者当前的 “发布（release）” 分支），并且 “主（main）” 分支应该被标记上更新后的版本号。
拥有专门的错误修复开发线，能让你的团队在不中断其余工作流程或不等待下一个发布周期的情况下解决问题。你可以把维护分支看作是专门直接与 “主（main）” 分支打交道的临时 “发布（release）” 分支。可以通过以下方法创建 “热修复（hotfix）” 分支：
不使用 git-flow 扩展时：
git checkout main
git checkout -b hotfix_branch
使用 git-flow 扩展时：
$ git flow hotfix start hotfix_branch
与完成 “发布（release）” 分支类似，“热修复（hotfix）” 分支会被合并到 “主（main）” 分支和 “开发（develop）” 分支。
git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch
$ git flow hotfix finish hotfix_branch
示例
下面是一个展示功能分支流程的完整示例。假设我们有一个带有 “主（main）” 分支的仓库设置。
git checkout main
git checkout -b develop
git checkout -b feature_branch
# 在功能分支上进行开发工作
git checkout develop
git merge feature_branch
git checkout main
git merge develop
git branch -d feature_branch
除了功能和发布流程外，热修复的示例如下：
git checkout main
git checkout -b hotfix_branch
# 完成修复工作，并将提交添加到热修复分支
git checkout develop
git merge hotfix_branch
git checkout main
git merge hotfix_branch
总结
在这里，我们讨论了 Gitflow 工作流。Gitflow 是你和你的团队可以使用的众多 Git 工作流风格之一。
关于 Gitflow，一些关键要点如下：
- 该工作流非常适合基于发布的软件工作流程。
- Gitflow 为生产环境的热修复提供了专门的渠道。
Gitflow 的整体流程是：
- 从 “主（main）” 分支创建 “开发（develop）” 分支
- 从 “开发（develop）” 分支创建 “发布（release）” 分支
- 从 “开发（develop）” 分支创建 “功能（feature）” 分支
- 当一个 “功能（feature）” 完成后，将其合并到 “开发（develop）” 分支
- 当 “发布（release）” 分支完成后，将其合并到 “开发（develop）” 分支和 “主（main）” 分支
- 如果在 “主（main）” 分支中发现问题，从 “主（main）” 分支创建 “热修复（hotfix）” 分支
- 一旦 “热修复（hotfix）” 完成，将其合并到 “开发（develop）” 分支和 “主（main）” 分支
