[Gitflow Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) 是一个 Git 工作流，有助于持续软件开发和实施 DevOps 实践。 它由文森特·德里森 (Vincent Driessen) 在 nvie 首次出版并广受欢迎。 Gitflow 工作流定义了围绕项目发布设计的严格分支模型。 这为管理大型项目提供了一个强大的框架。

Gitflow 非常适合具有预定发布周期的项目以及持续交付的 DevOps 最佳实践。 除了功能分支工作流所需的内容之外，此工作流不会添加任何新概念或命令。 相反，它为不同的分支分配非常具体的角色，并定义它们应该如何以及何时交互。 除了功能(feature)分支之外，它还使用单独的分支来准备、维护和记录发布。 当然，您还可以利用 Feature Branch Workflow 的所有优势：拉取请求、独立实验和更高效的协作。

# Getting Started

Gitflow 实际上只是 Git 工作流的一个抽象概念。 这意味着它决定了要设置什么样的分支以及如何将它们合并在一起。 我们将触及以下分支的目的。 git-flow 工具集是一个具有安装过程的实际命令行工具。 git-flow 的安装过程很简单。 git-flow 软件包可在多个操作系统上使用。 在 OSX 系统上，您可以执行 brew install git-flow。 在 Windows 上，您需要下载并安装 git-flow。 安装 git-flow 后，您可以通过执行 git flow init 在您的项目中使用它。 Git-flow 是 Git 的包装器。 git flow init 命令是默认 git init 命令的扩展，除了为您创建分支外，不会更改存储库中的任何内容。

# How it works

![](https://img-blog.csdnimg.cn/img_convert/929945561b3ce6b90a2679b19ccc580c.png)

# Develop and Main Branches

此工作流使用两个分支来记录项目的历史记录，而不是单个 main 分支。 Main 存储官方发布历史，开发分支作为功能的集成分支。 用版本号标记主分支中的所有提交也很方便。

第一步是用一个 develop 分支补充默认的主分支。 一种简单的方法是让开发人员在本地创建一个空的 develop 分支并将其推送到服务器：

```shell
git branch develop
git push -u origin develop
```

该分支将包含项目的完整历史记录，而 main 将包含一个删节版本。 其他开发人员现在应该克隆中央存储库并为 develop branch 创建一个跟踪分支。

# Feature Branches

每个新功能都应该驻留在自己的分支中，可以将其推送到中央存储库进行备份/协作。 但是，feature 分支不是从 main 分支出来，而是使用 ``develop`` 作为它们的父分支。 当一个功能完成时，它会被合并回 develop branch 。 功能不应该直接与 main branch 交互。

![](https://img-blog.csdnimg.cn/img_convert/8e537f921c8a2a5c1582cab1b433e706.png)

请注意， feature 分支与 develop 分支相结合，就所有意图和目的而言，都是功能分支工作流。 但是，Gitflow 工作流并不止于此。

feature 分支通常基于最新的开发分支创建。

# Creating a feature branch

```shell
git checkout develop
git checkout -b feature_branch
```

# Finishing a feature branch

当您完成该功能的开发工作后，下一步是将 feature_branch 合并到 develop 中。

```shell
git checkout develop
git merge feature_branch
```

# Release Branches

![](https://img-blog.csdnimg.cn/img_convert/52692ff8fbaafd5708e7064d940ae8f8.png)

一旦 develop 获得了足够的发布功能（或预定的发布日期即将到来），您就可以从 develop 中分出一个 release 分支。创建此分支将启动下一个发布周期，因此在此之后不能添加任何新功能——只有错误修复、文档生成和其他面向发布的任务应该在此分支中进行。

一旦准备好发布， release 分支就会合并到 main 分支并标记一个版本号。此外，它应该合并回 develop branch，自发布开始以来，后者可能已经取得了进展。

使用一个专门的分支来准备发布可以让一个团队完善当前版本，而另一个团队继续为下一个版本开发功能。它还创建了明确定义的开发阶段（例如，很容易说“本周我们正在为 4.0 版做准备”，并在存储库的结构中实际看到它）。

制作 release 分支是另一个简单的分支操作。与功能分支一样，release 分支基于 develop 分支。可以使用以下方法创建新的发布分支。

```shell
git checkout develop
git checkout -b release/0.1.0
```

一旦发布准备好发布，它将合并到 main 和 develop，然后Release 分支将被删除。 合并回 develop 很重要，因为关键更新可能已添加到 Release 分支，并且需要新功能可以访问它们。如果您的组织强调代码审查，这将是拉取请求的理想场所。

要完成发布分支，请使用以下方法：

```shell
git checkout main
git merge release/0.1.0
```

# Hotfix Branches

![](https://img-blog.csdnimg.cn/img_convert/99f61bbaf6f7841c24358570df698a18.png)

Maintenance 或“hotfix”分支用于快速修补生产版本。 Hotfix 分支很像 release 分支和 feature 分支，只是它们基于 main 而不是 develop。 这是唯一应该直接从 main 分叉出来的分支。 修复完成后，应将其合并到 main 和 develop（或当前 release 分支）中，并且 main 应使用更新的版本号进行标记。

拥有专门的错误修复开发线，您的团队可以在不中断工作流程的其余部分或等待下一个发布周期的情况下解决问题。 您可以将 Maintenance 分支视为直接与 main 一起工作的临时 release 分支。 可以使用以下方法创建修补程序分支：

```shell
git checkout main
git checkout -b hotfix_branch
```

类似于完成发布分支，修补程序分支合并到主分支和开发分支。

```shell
git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch
```

# 总结

* develop 分支是从 main 分支创建的
* 从 develop 创建一个 Release 分支
* feature 分支是从 develop 创建的
* 当一个功能完成时，它会被合并到 develop 分支中
* release 分支完成后，它会合并到 develop 和 main
* 如果在 main 中检测到问题，则从 main 创建一个 hotfix 程序分支
* 修补程序完成后，它将合并到 develop 和 main 分支

ITPub博客

大型开发项目中 git 工作流的最佳实践

最新文章