源本科技 | 码上会

logo
源本科技 码上会
一站式数字化转型技能学习平台

Git Flow 工作流

2026/04/09
2
0

引言

在实际工作中，有多种 Git 工作流程可供选择，企业团队最常用的工作流如下：

  • Centralized Workflow

    • 集中式工作流：所有开发者将更改提交到共享的中央仓库，协作方式简单，但容易产生代码协调问题。

    • 适用场合：小型项目、小规模团队，用于简化版本控制流程。

  • Feature Branch Workflow

    • 特性分支工作流：每个新功能在独立分支开发，完成后合并回主分支，版本历史清晰，支持并行开发。

    • 适用场合：中等规模项目，需要并行开发多个功能，且对功能合并有严格管控的场景。

  • Gitflow Workflow

    • GitFlow 工作流：基于分支管理的标准化工作流模型，定义了严格的分支规范与流程，包含主分支、开发分支、特性分支、发布分支、热修复分支，用于规范化团队协作与版本发布。

    • 适用场合：大型项目、有固定版本发布周期、需要长期维护多版本的项目。

  • Forking Workflow

    • 分叉工作流：基于 Fork + Pull Request 的协同模式，开发者在个人仓库独立开发，通过 PR 向原仓库合并代码，保证主仓库纯净。

    • 适用场合：大型开源项目、多外部贡献者参与的项目。

注意：以上 Git 工作流程仅为指导方针，而非固定规则，可根据团队实际情况组合使用。

GitFlow

GitFlow 是一种以项目发布为核心的 Git 工作流，通过严谨的分支创建与管理策略，规范团队代码协作行为。Git 创建分支成本极低，支持多层级分支开发与合并。

特性分支策略（Feature Branch Workflow）是 GitFlow 的基础，核心原则：

  • 所有功能开发不在主干直接进行，而是在独立分支完成

  • 半成品功能不会污染主干代码

  • 开发人员互不干扰

  • 主干始终保持可编译、可上线的稳定状态

GitFlow 在特性分支基础上，进一步规范了分支创建、合并、版本发布、历史版本修复的完整流程。

常用分支说明

名称

说明

master

主分支，存放稳定可发布的生产代码，仅接受合并，禁止直接修改

develop

开发分支，集成所有功能分支的最新开发代码

feature

特性分支，用于新功能开发

hotfix

热修复分支，用于线上紧急 BUG 修复

release

发布分支，用于版本发布前的测试与小修复

GitFlow 中的分支

GitFlow 的核心是分支管理，整体分为主分支与辅助分支两类：

  • 主分支：长期存在，永久保留

    • master

    • develop

  • 辅助分支：临时存在，使用完成后会删除

    • feature

    • release

    • hotfix

主要分支

master

  • master 存放可直接上线的稳定正式版本，任何时候都可用于生产环境。

  • 每次版本发布后，都需要在 master 上打版本标签（Tag）。

  • 严禁直接在 master 上提交代码，只能从 release 或 hotfix 分支合并。

master 仅用于保存历史发布版本，通过 Tag 标记版本号，如 v 0.1、v 0.2。

develop

  • develop 是日常开发的主分支，存放下一个版本的最新开发代码。

  • 当 develop 达到稳定状态，可从中拉出发布分支准备上线。

  • 只接受 feature、release、hotfix 分支的合并，合并代码必须保证功能完整、不破坏分支稳定性。

develop 用于整合所有 feature 分支，是团队开发的核心分支。

功能分支

feature

  • 分支命名规范：feature/功能名，如 feature/login、feature/pay。

  • 用于开发新版本功能，从 develop 分支拉出。

  • 开发完成后合并回 develop 分支，废弃无用的功能分支可直接删除。

  • 多人协作同一功能时，需推送到远程仓库；单人开发可仅保留在本地。

所有新功能都在独立 feature 分支开发，与 master 无直接关联。

预发布分支

release

  • 分支命名规范：release/版本号，如 release/0.1.0、release/1.2.0。

  • 从 develop 拉出，专门用于发布前测试、小 Bug 修复、版本号修改等发布准备工作。

  • 该分支不添加新功能，只做修复与优化。

  • 发布完成后，同时合并回 develop 和 master，然后删除。

使用 release 分支的优势：

  • 不影响 develop 继续开发下一版本功能

  • 集中处理发布相关工作，流程清晰

  • 测试、修复、文档编写可独立进行

热修复分支

hotfix

  • 分支命名规范：hotfix/版本号，如 hotfix/0.1.1、hotfix/1.2.1。

  • 线上 master 分支出现紧急 Bug 时使用，从 master 对应 Tag 拉出。

  • 修复完成后，同时合并到 master 和 develop，并在 master 打新标签。

  • 不影响 develop 正常开发，实现功能开发与线上修复并行。

不直接在 develop 修复线上 Bug 的原因：

  • develop 包含未验证的新功能

  • 线上用户不需要未发布的功能

  • develop 不能立即发布，而线上 Bug 需要紧急修复

GitFlow 实践

创建开发分支

# 创建 develop 分支
git branch develop

# 将 develop 分支推送到远端，并建立追踪关系
git push -u origin develop

开始新的功能特性分支

# 从 develop 分支新建 feature 分支
git checkout -b feature/分支名 develop

# 可选：推送到远程仓库（多人协作时使用）
git push -u origin feature/分支名

编辑功能特性分支

# 查看文件状态
git status

# 添加文件到暂存区
git add 文件名

# 提交到本地仓库
git commit -m "提交说明"

完成功能特性分支

# 拉取远程最新 develop 代码，保持本地最新
git pull origin develop

# 切换到 develop 分支
git checkout develop

# 合并 feature 分支，--no-ff 保留完整分支历史
git merge --no-ff feature/分支名

# 推送到远程 develop 分支
git push origin develop

# 删除本地 feature 分支
git branch -d feature/分支名

# 可选：删除远程 feature 分支
git push origin --delete feature/分支名

开始预发布

# 从 develop 创建 release 分支
git checkout -b release/0.1.0 develop

完成预发布

# 合并到 master
git checkout master
git merge --no-ff release/0.1.0
git push

# 同时合并回 develop
git checkout develop
git merge --no-ff release/0.1.0
git push

# 删除 release 分支
git branch -d release/0.1.0

开始热修复

# 从 master 创建 hotfix 分支
git checkout -b hotfix/0.1.1 master

完成热修复

# 合并到 master
git checkout master
git merge --no-ff hotfix/0.1.1
git push

# 合并到 develop
git checkout develop
git merge --no-ff hotfix/0.1.1
git push

# 删除 hotfix 分支
git branch -d hotfix/0.1.1

# 为 master 打版本标签
git tag -a v0.1.1 -m "修复线上紧急问题"

# 推送标签到远程
git push --tags

GitFlow 实战

下面以真实团队场景演示 GitFlow 完整发布流程，假设中央仓库已创建。

创建开发分支

第一步为默认的 master 分支配套 develop 分支，由一名开发者本地创建后推送到远程。

git branch develop
git push -u origin develop

推送完成后，远程仓库即可看到 develop 分支。

远程服务器中可查看已创建的 develop 分支。

其他开发者克隆仓库后，创建本地 develop 追踪分支：

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

至此，所有开发者本地都拥有完整的 develop 开发分支。

开发新功能

团队成员分别开发新功能，必须从 develop 拉出功能分支，不能使用 master。

git checkout -b feature/某功能 develop

功能开发遵循标准流程：

git status
git add 文件名
git commit -m "功能开发说明"

切换到功能分支开始开发。

功能开发完成

功能开发完毕后，先同步远程最新代码，再合并到 develop：

# 拉取最新 develop 代码
git pull origin develop

# 切换到本地 develop
git checkout develop

# 合并功能分支
git merge feature/某功能

# 推送到远程
git push

# 删除本地功能分支
git branch -d feature/某功能

合并前必须拉取最新代码，避免冲突；功能代码永远不直接合并到 master。

将功能分支合并进开发分支。

推送更新后的分支到远程。

删除已完成的本地功能分支。

若远程存在功能分支，一并删除。

再次推送全部分支到远程。

准备预发布

功能开发到一定阶段后，从 develop 创建 release 分支，准备版本发布：

git checkout -b release/0.1 develop

该分支仅用于：

  • 测试

  • 小 Bug 修复

  • 版本号、发布文档完善

  • 不开发新功能

分支创建并推送后，当前版本包含的功能就已固定。

完成预发布

发布测试完成后，将 release 分支同时合并到 master 和 develop，再删除发布分支。

git checkout master
git merge release/0.1
git push

git checkout develop
git merge release/0.1
git push

git branch -d release/0.1

切换到主分支。

合并预发布分支。

提交并推送主分支。

切换到开发分支。

合并预发布分支。

推送 develop 分支，删除 release 分支后再次推送。

发布完成后，必须为 master 打上版本标签：

git tag -a 0.1 -m "Initial public release" master
git push --tags

Git 支持 Hook 机制，可在推送 master 或 Tag 时触发自动构建。

基于主分支创建标签。

推送主分支与标签。

远程仓库可查看已创建的版本标签。

完成热修复

线上版本出现紧急 Bug 时，从 master 创建热修复分支：

git checkout -b issue-#001 master

# 修复 Bug 后提交
git checkout master
git merge issue-#001
git push

基于主分支创建修复分支。

修复完成后合并回 master 并推送。

热修复的代码必须同时合并到 develop，保证开发分支也包含修复：

git checkout develop
git merge issue-#001
git push

git branch -d issue-#001

切换到 develop 合并修复分支并推送。

最后删除本地热修复分支。