Portfolio
← 返回博客列表
Git Flow

2026-08-09 · 阅读 1

Git Flow

Git Flow

Git Flow

1.理论基础：gitflow是一套分支管理策略，用不同的分支承担不同的职责，让开发和发布井井有条，目标就是为了多人协作的时候，如果大家都往main上直接推代码，会一团糟，版本号混乱。 2.五大核心分支

main ────────────────────────────────── 生产代码（随时可部署，线上生产代码，永远稳定）
  │
  └─ hotfix/* ── 紧急修复线上问题（从main拉取代码）

develop ─────────────────────────────── 集成分支（所有功能的汇聚点，开发集成分支包含最新的开发成果）
  │
  ├─ feature/* ── 开发新功能
  └─ release/* ── 发布准备（测试、改版本号，从develop拉，做发布前的测试和修复bug）

3.分支的生命周期

          feature/login
          ┌─────┐
develop ──┤     ├──(合并)──→ develop
          └─────┘
//从develop（主分支）拉出专属功能分支feature/login，专门开发登录模块，不直接在develop上乱改

流向规则：功能开发测试完成后，**仅合并回 develop 分支**，不会触碰 main 线上分支。
✅ 作用：隔离新功能开发，多个 feature 分支可并行开发，互不干扰，稳定后再汇总到开发主干 develop。

          release/1.0
          ┌─────┐
develop ──┤     ├──(合并)──→ main  （打tag v1.0）
          └─────┘──(合并)──→ develop

//从develop拉出release/1.0发布分支，这个阶段不加新的功能，只做上线前的bug修复，版本测试和文档整理

流向规则：1. 测试验收通过 → 合并到**main（生产主干分支）**，同时给 main 打上版本标签`v1.0`，正式对外发版；
2. 把 release 分支里修复的 bug 代码，**同步合并回 develop**，保证开发分支也包含这些修复，避免后续开发重复踩坑。
✅ 作用：做开发环境到生产环境的过渡闸门，隔离 “功能开发期” 和 “上线稳定期”，保障发版质量。

          hotfix/1.0.1
          ┌─────┐
main ─────┤     ├──(合并)──→ main  （打tag v1.0.1）
          └─────┘──(合并)──→ develop

//直接从线上稳定mian分支拉出hotfix/1.0.1热修复分支，紧急处理线上生产环境的致命bug

### 双向合并流向
1. 修复验证完成 → 先合并回**main 生产分支**，打新版本标签`v1.0.1`，快速上线修复线上故障；
2. 再把线上修复的代码**同步合并回 develop 开发分支**，让后续迭代版本也带上这个 bug 修复，不会旧问题复现。
✅ 作用：线上故障快速闭环，同时保证开发、生产两侧代码修复同步。

4.为什么合并要用--no--ff 普通合并（fast-forward）会直接把分支指针前移，丢失“这里做过合并”的历史记录， --no-ff会强制创建一个合并提交节点，这样在git log里能看到：“这是xx合并进来的点”

git merge --no-ff feature/login

5.工作流程：

  • 从 develop 拉 feature/login
  • 在 feature/login 上写代码，提交多次
  • 开发完毕，用 --no-ff 合并回 develop ， 删除 feature 分支
  • 当 develop 上积累了足够功能，准备发版
  • 从 develop 拉 release/1.0 ，做测试、改版本号
  • 测试通过， release/1.0 合并到 main （打 tag）和 develop ， 删除 release 分支
  • 突然线上发现 bug，从 main 拉 hotfix/1.0.1 修复
  • 修完合并到 main （打 tag）和 develop ， 删除 hotfix 分支

四、实战演练

以下操作均以真实项目为例，master 分支为线上稳定代码。

Step 1：建立 develop 分支

# 确认当前在 master 上
git branch

# 基于 master 创建 develop 并切换
git checkout -b develop

# 确认切换成功
git branch

输出：

  master
* develop

Step 2：从 develop 拉 feature 分支开发功能

# 从 develop 创建 feature/visit-stats 分支
git checkout -b feature/visit-stats

# 模拟开发：创建功能文件
mkdir web/utils
echo "// 访问统计功能模块" > web/utils/visit-stats.js
git add web/utils/visit-stats.js
git commit -m "feat: 添加访问统计模块"

# 继续开发：多步提交
echo "// 访问统计 - 图表展示" > web/utils/visit-chart.js
git add web/utils/visit-chart.js
git commit -m "feat: 添加访问统计图表展示"

# 确认状态
git log --oneline -3

Step 3：feature 合并回 develop，删除 feature 分支

# 切回 develop
git checkout develop

# 用 --no-ff 合并（保留合并节点）
git merge --no-ff feature/visit-stats -m "merge: 合并访问统计功能到 develop"

# 确认合并成功
git log --oneline -4

# 删除已完成的 feature 分支
git branch -D feature/visit-stats

# 确认分支已删除
git branch

为什么用 --no-ff？ 普通合并（fast-forward）会丢失合并历史记录。--no-ff 强制创建合并提交节点，在 git log 中能清楚看到每个功能的合并点。

Step 4：拉 release 分支，准备发布

# 从 develop 创建 release/1.0.0
git checkout -b release/1.0.0

# 模拟修改版本号
echo "v1.0.0" > web/utils/visit-chart.js
git add web/utils/visit-chart.js
git commit -m "release: 更新版本号到 v1.0.0"

# 合并到 master（上线！）
git checkout master
git merge --no-ff release/1.0.0 -m "release: 发布 v1.0.0 到生产环境"

# 打 tag 标记版本
git tag -a v1.0.0 -m "版本 1.0.0"

# 同步回 develop（版本号等改动也要同步）
git checkout develop
git merge --no-ff release/1.0.0 -m "merge: 将 release/1.0.0 同步回 develop"

# 删除 release 分支
git branch -D release/1.0.0

Step 5：模拟 hotfix（紧急修复线上 bug）

# 从 master 拉出 hotfix 分支
git checkout master
git checkout -b hotfix/1.0.1

# 模拟修复 bug
echo "v1.0.1 - 修复线上bug" > web/utils/visit-chart.js
git add web/utils/visit-chart.js
git commit -m "hotfix: 修复访问统计图表显示异常"

# 合并回 master（紧急上线！）
git checkout master
git merge --no-ff hotfix/1.0.1 -m "hotfix: 紧急发布 v1.0.1"

# 打 tag
git tag -a v1.0.1 -m "版本 1.0.1 - 紧急修复"

# 同步回 develop（防止 develop 也有这个 bug）
git checkout develop
git merge --no-ff hotfix/1.0.1 -m "merge: 将 hotfix/1.0.1 同步回 develop"

# 删除 hotfix 分支
git branch -D hotfix/1.0.1

# 确认最终状态
git branch
git tag -l

Step 6：可视化回顾分支历史

git log --graph --oneline --all --decorate

输出：

*   ec96d13 (HEAD -> develop) merge:将hotfix/1.0.1同步develop
|\
| | *   202f249 (tag: v1.0.1, master) hotfix:紧急发布 v1.0.1
| | |\
| | |/
| |/|
| * | 27d93b9 hotfix:修复访问统计图表显示异常
| |/
| * 052d974 (tag: v1.0.0) release:发布v1.0.0到生产环境
|/|
| * e61b22b release: 更新版本号到 v1.0.0
|/
* 652734b (origin/master) feat: blog cover image, upload fix, cleanup repo
...

五、适用场景

适合 Git Flow不适合 Git Flow
有明确版本发布计划（v1.0、v2.0）持续部署，每天多次发布
需要同时维护多个版本两三个人的小项目
有专门的测试/发布流程—

六、常用命令速查表

操作命令
创建 featuregit checkout -b feature/xxx develop
完成 featuregit checkout develop → git merge --no-ff feature/xxx → git branch -D feature/xxx
创建 releasegit checkout -b release/x.y.z develop
完成 releasegit checkout master → git merge --no-ff release/x.y.z → git tag -a vx.y.z → git checkout develop → git merge --no-ff release/x.y.z → git branch -D release/x.y.z
创建 hotfixgit checkout -b hotfix/x.y.z master
完成 hotfix同 release 流程
查看分支图git log --graph --oneline --all --decorate

七、总结

Git Flow 的核心就三句话：

feature：从 develop 来，回 develop 去 release：从 develop 来，回 master + develop 去 hotfix：从 master 来，回 master + develop 去

掌握这三个流向，就掌握了 Git Flow 的精髓。配合 --no-ff 合并和 tag 标记，团队的版本管理将清晰可追溯。