GitFlow 教程：为功能、发布和热修复进行分支管理

设置 GitFlow

在利用 GitFlow 的结构化分支模型之前，您需要在本机上完成安装设置，并在仓库中初始化。好在这两步都很简单。

要使用 GitFlow，您应当已经在本机安装了 Git。关于安装 Git 的更多信息，请参阅Git 安装教程。

安装 GitFlow

GitFlow 是 Git 的扩展，因此需要单独安装。默认情况下，它并不与 Git 一起打包。安装方式取决于您的操作系统。

有关更详细的安装说明，请阅读 官方文档。

注意：虽然上述 GitFlow 扩展可通过简单命令更轻松地管理功能分支、发布和热修复，但它并非严格必需。您也可以使用标准的Git 命令 按照 GitFlow 工作流进行操作——只要在命名约定和合并实践上保持一致即可。该工具只是将流程自动化并加以约束，这对团队或大型项目很有帮助。

macOS

如果您使用的是 Homebrew（macOS 上最流行的软件包管理器），运行：

brew install git-flow-avh技术支持

Linux（基于 Debian/Ubuntu）

如果您使用的是 Debian 系统（如 Ubuntu），请使用：

sudo apt-get install git-flow技术支持

Windows

如果您在 Windows 上，可通过 Git for Windows 安装 GitFlow，并在终端中添加 Git Bash。

要检查是否已安装 GitFlow，您可以运行：

git flow version技术支持

在仓库中初始化 GitFlow

首先，您需要先初始化一个 Git 仓库，才能使用 GitFlow。可阅读 如何初始化并设置 Git 仓库。

安装完成后，您可以在任意现有 Git 仓库中运行以下命令进行初始化：

git flow init技术支持

GitFlow 会提示您配置若干设置。以下是各项含义以及如何选择合适配置：

1. 分支名称：系统会询问默认分支名。
1. 生产分支名称（默认：master）
2. 开发分支名称（默认：develop）
2. 辅助分支前缀：GitFlow 为不同类型的分支使用命名约定。
1. 功能分支：feature/
2. 缺陷修复分支：bugfix/
3. 发布分支：release/
4. 热修复分支：hotfix/
5. 支持分支：support/（实际中很少使用）
6. 版本标签前缀：v（例如 v.1.2.0）

默认设置对大多数团队都适用，但您也可以根据组织的命名规范进行自定义。

初始化输出示例：

git flow init

Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [] v技术支持

初始化完成后，您可以将 develop 分支推送到远程仓库。关于如何推送与拉取分支，可参阅 Git Push 和 Pull 教程。

在开发中使用 GitFlow

在仓库中初始化 GitFlow 后，您就可以开始用其分支模型来管理开发工作流。GitFlow 为功能开发、发布与热修复提供了高级命令，帮助您保持结构清晰，避免 Git 混乱。

接下来我们将在各小节中实践 GitFlow。

创建功能分支

功能分支用于开发新功能，而不会影响主代码库。

您可以通过运行以下命令创建功能分支：

git flow feature start <feature-name>技术支持

该命令将基于 develop 创建名为 feature/<feature-name> 的新分支。您可以开始开发功能，并像往常一样提交更改。

完成功能分支

当功能开发完成并通过测试后，您可以使用以下命令完成它：

git flow feature finish <feature-name>技术支持

该命令将执行以下操作：

• 将功能分支合并到 develop 分支。
• 删除本地的 feature/<feature-name> 分支。

如果遇到合并冲突，请手动解决并使用 Git 的标准冲突解决流程完成合并。

如果您在较大的团队中工作，需要先创建并审核拉取请求（PR），那么您不能直接使用 GitFlow 的 finish 命令，而应改为如下操作：

1. 提交您的工作，然后推送分支：

git push origin feature/<feature-name>技术支持

2. 在 GitHub、GitLab 等平台上，从 feature/<feature-name> 向 develop 创建拉取请求。
3. 请求评审、运行测试并获得批准。
4. 获批后通过平台的界面合并并删除分支。

如果您想进一步了解 GitHub 及其使用方法，我推荐课程 GitHub Foundations 和 GitHub Concepts。在其他团队中，您也可能遵循标准的 git flow feature finish 流程，但在合并回 develop 之前需要请求评审，并对代码变更运行测试以确保行为正确。

创建发布分支

发布分支用于在不阻塞 develop 分支上持续开发的情况下，准备新的生产版本。

要开始一个发布，请运行：

git flow release start <version-number>技术支持

这会创建一个名为 release/<version-number> 的新分支。该分支基于 develop 派生。

在这个分支中，通常会定版版本号、修复小问题，以及更新文档和变更日志。

完成发布分支

当您的发布已准备好进入生产环境时，使用以下命令完成它：

git flow release finish <version-number>技术支持

该命令将：

• 将发布分支合并到 master 和 develop。
• 在 master 上为发布打标签（例如 v1.0.0）。
• 删除本地的 release/<release-number> 分支。

别忘了推送您的更改和标签：

git push origin master
git push origin develop
git push --tags

# or in short
git push origin master develop --tags技术支持

创建热修复分支

当在 master 分支上发现缺陷时，热修复用于对生产环境进行紧急修复。

开始一个热修复：

git flow hotfix start <version-number>技术支持

这会基于 master 创建一个 hotfix/<version-number> 分支。您现在可以提交修复变更。

完成后，使用以下命令结束：

git flow hotfix finish <version-number>技术支持

该命令将：

• 将热修复合并到 master 和 develop。
• 在 master 上为修复打标签。
• 删除本地的 `hotfix/<version-number> 分支。

像往常一样推送本地更改和标签：

git push origin master develop --tags技术支持

热修复尤其强大，因为它允许您在不干扰 develop 分支上正在进行的开发的情况下，快速修复生产问题。

想象一下，某些新功能已经合并到 develop，但您还不想发布它们，同时生产应用出现了紧急且严重的缺陷需要修复。

这时热修复就派上用场了，因为它从 master 派生，随后只合并回 develop。

GitFlow 分支示例

我们来走一遍两种常见工作流：一个功能开发周期，以及一个包含热修复的发布，以便看到 GitFlow 的实际运作，并与传统 Git 命令进行对比。

通过对比两种方式，您将更好地理解 GitFlow 扩展如何将多个 Git 步骤封装为简单、标准化的命令，从而简化流程。

如果您需要快速回顾传统 Git 命令，推荐查看 Git 速查表（完整版）。若想快速了解 Git，建议阅读 GitHub 和 Git 初学者教程。

功能开发工作流

假设您正在实现一个新功能，允许用户在应用中进行认证。您将该功能命名为 user-authentication。

使用 GitFlow：

git flow feature start user-authentication

# Work on the feature
git add .
git commit -m "feat: Implement basic user authentication"

# Once finished:
git flow feature finish user-authentication

git push origin develop技术支持

使用常规 Git：

# Create and switch to a new branch manually
git checkout -b feature/user-authentication develop

# Work on the feature
git add .
git commit -m "Implement basic user authentication"

# Once finished
git checkout develop
git merge feature/user-authentication
git branch -d feature/user-authentication
git push origin develop技术支持

如您所见，GitFlow 减少了命令数量，从而降低了复杂度，也更不易出错，例如不小心合并到错误分支。

想进一步了解 Git 合并的工作原理，请阅读 Git 合并教程：含示例的全面指南。

现在，假设您正在准备发布 1.0.0。但在发布新版本不久后，发现了一个需要通过热修复解决的严重缺陷。

使用 GitFlow：

# Start a release
git flow release start 1.0.0

# Make final tweaks, update version numbers
git commit -am "Prepare release v1.0.0"

# Finish the release
git flow release finish 1.0.0
git push origin master develop --tags技术支持

现在您发现了该缺陷，需要创建热修复：

# Start a hotfix
git flow hotfix start 1.0.1

# Apply the fix
git commit -am "Fix login issue in production"

# Finish the hotfix
git flow hotfix finish 1.0.1
git push origin master develop --tags技术支持

再用常规 Git 命令完成上述过程：

# Release manually
git checkout -b release/1.0.0 develop

# Make changes
git commit -am "Prepare release v1.0.0"

# Merge manually
git checkout master
git merge release/1.0.0
git tag -a v1.0.0 -m "Release v1.0.0"
git checkout develop
git merge release/1.0.0

# Delete release branch
git branch -d release/1.0.0
git push origin master develop --tags

# Hotfix manually
git checkout -b hotfix/1.0.1 master

# Apply fix
git commit -am "Fix login issue in production"
git checkout master
git merge hotfix/1.0.1
git tag -a v1.0.1 -m "Hotfix v1.0.1"
git checkout develop
git merge hotfix/1.0.1

# Delete hotfix branch
git branch -d hotfix/1.0.1
git push origin master develop --tags技术支持

使用 GitFlow 的最佳实践

GitFlow 非常强大，有助于管理团队代码。但要最大化发挥其作用，您应遵循一些最佳实践。

这些做法有助于保持分支整洁、减少合并冲突，并提升团队生产力，尤其在协作环境中尤为重要。

一致的分支命名

一致性是协作的关键。除非团队有充分理由自定义，否则请坚持使用 GitFlow 的默认命名约定。

推荐命名模式：

• 功能分支：feature/<feature-name>
• 发布分支：release/<version-number>
• 热修复分支：hotfix/<version-number>

多词名称也应使用 kebab-case（例如 feature/user-authentication）。

小步快跑，频繁提交

长期存在的分支往往会导致痛苦的合并，以及难以审查的庞大拉取请求。

我深有体会，曾多次经历合并冲突的“地狱”，能避免尽量避免！

因此，请尽量让功能分支短期存活，并聚焦于单一任务。定期提交并推送，避免丢失工作或与 develop 偏离过远。

更小、更渐进的变更更易于测试、审查和集成。

定期与 develop 同步

在功能分支上工作时，切勿“掉队”。请定期从 develop 拉取最新更改，以尽可能减少后续的合并冲突：

git checkout feature/<your-feature>
git fetch origin
git rebase origin/develop技术支持

保持同步可使集成更顺畅，并确保您的更改与他人正在构建的功能兼容。

合并前先评审与测试

尽管 GitFlow 支持使用 git flow feature finish 等命令直接合并，但最佳做法是在合并到 develop 和 master 时使用拉取请求（PR）或合并请求（MR）。

好处：

• 启用代码评审与审批流程
• 触发自动化 CI/CD 检查
• 提供清晰的变更审计追踪

这在重视质量控制的生产级环境中尤为关键。

GitFlow 故障排查

即便采用像 GitFlow 这样的结构化流程，问题仍可能出现，尤其是在团队协作或长期存在的分支中。

本节将介绍最常见的挑战及其有效解决方法。

合并冲突

在较大团队中共同维护同一代码库时，合并冲突很常见，也很烦人。它通常发生在两个分支修改了同一行代码时。

解决合并冲突的步骤：

1. 停止 git flow finish 过程。
2. 手动将分支合并到其目标分支：

git checkout develop
git merge feature/<your-feature>技术支持

3. Git 会提示您解决冲突。打开有冲突的文件，查找如下的冲突标记：

<<<<<<< HEAD
Code from develop
=======
Code from feature branch
>>>>>>> feature/my-feature技术支持

4. 手动编辑并清理代码。
5. 解决后，将文件标记为已解决：

git add <resolved-file>技术支持

6. 然后通过以下命令完成合并：

git commit -m “resolve merge conflict …”技术支持

清理陈旧分支

有时，您的仓库中会包含过时的 feature、release 或 hotfix 分支。为避免混淆，请尽可能保持仓库整洁。

可按以下步骤进行清理：

1. 列出所有本地分支：

git branch技术支持

2. 删除本地分支：

git branch -d <branch-name>技术支持

3. 如果该分支尚未合并，且您确认可以删除：

git branch -D <branch-name>技术支持

4. 删除远程分支：

git push origin --delete <branch-name>技术支持

定期检查并清理陈旧分支，对保持仓库整洁至关重要。

结语

GitFlow 是一个稳健的框架，能为您的开发工作流带来协作、清晰与可控。无论是独立项目中有更多人参与，还是为大型团队做贡献，GitFlow 都通过清晰地分隔功能开发、发布和热修复，帮助您保持井然有序。

我刚开始用 GitFlow 时，感觉就像换了游戏规则。不再有合并混乱，不再需要猜测该用哪个分支。每项工作都有去处，每次发布都有可重复、可靠的流程。此后，我把 GitFlow 引入我参与过的每个团队，每一次都带来了更有序的结构、更顺畅的协作和更少的失误。

在本教程中，您学到了：

• 什么是 GitFlow，以及它为何有用
• 如何安装和初始化 GitFlow
• 如何使用功能分支、发布分支与热修复分支
• 避免常见问题的最佳实践
• 如何通过拉取请求将 GitFlow 适配到现代工作流

如果您准备将 Git 工作流提升到新水平，请在下一个项目中尝试使用 GitFlow。如果您已熟悉基础用法，不妨开始考虑将其与团队的 CI/CD 流水线、评审流程，甚至 GitHub Actions 集成。