第 6 课：团队协作标准工作流（Git Flow）
学完前面的内容，你已经掌握了 Git 的基础操作、远程仓库和分支管理。
但在真实公司项目中，开发人员并不会直接在 main 分支上写代码，而是遵循一套团队协作规范。
这一课将学习企业中最常见的 Git Flow 工作流。
6.1 什么是 Git Flow？
Git Flow 是一套基于 Git 分支管理的开发规范。
它的目标是：
让多人协作开发变得有序
避免代码混乱
保证线上代码稳定
例如：
main
存放线上运行代码。
dev
存放开发环境代码。
开发人员：
张三
李四
王五
各自在独立功能分支开发：
feature/login
feature/order
feature/user
开发完成后再统一合并。
6.2 为什么不能直接在 main 开发？
假设：
main
是线上运行中的项目。
此时你开发登录功能：
登录功能开发一半
突然：
线上需要紧急发布
怎么办？
如果直接在 main 开发：
main
├── 已完成代码
├── 未完成代码
└── Bug
根本无法上线。
所以：
main 永远保持稳定
成为团队开发的重要原则。
6.3 Git Flow 分支结构
企业中常见结构：
main
│
└── dev
│
├── feature/login
│
├── feature/order
│
└── feature/user
职责：
main
生产环境
线上运行代码
要求：
绝对稳定
dev
开发环境
团队开发主分支
所有功能最终都会合并到这里。
feature/*
功能分支
例如：
feature/login
feature/order
feature/article
每个功能一个分支。
bugfix/*
Bug 修复分支
例如：
bugfix/login-error
bugfix/order-timeout
用于紧急修复线上问题。
release/*
发布分支
例如：
release/v1.0.0
release/v2.0.0
用于版本发布前测试。
6.4 分支命名规范
推荐：
main
生产环境
dev
开发环境
feature/功能名
例如：
feature/user-login
feature/order-create
feature/article-comment
bugfix/问题名
例如：
bugfix/login-password-error
bugfix/order-timeout
release/版本号
例如：
release/v1.0.0
release/v2.0.0
6.5 开发新功能完整流程
假设：
开发用户登录功能
第一步：
切换到开发分支：
git checkout dev
拉取最新代码：
git pull origin dev
确保：
本地 dev
=
远程 dev
第二步：
创建功能分支：
git checkout -b feature/user-login
结构：
dev
└── feature/user-login
第三步：
开始开发。
例如：
登录页面
登录接口
JWT认证
开发过程中频繁提交：
git add .
git commit -m "完成登录页面布局"
git commit -m "完成登录接口开发"
git commit -m "实现JWT认证"
不要等功能全部完成再提交。
推荐：
完成一个小功能
提交一次
第四步：
推送到远程：
git push -u origin feature/user-login
形成：
本地 feature/user-login
↓
远程 feature/user-login
6.6 Pull Request（PR）
功能完成后。
不要直接：
合并到 dev
正确做法：
提交：
Pull Request
简称：
PR
PR 的作用：
代码审查
流程：
开发人员
↓
提交 PR
↓
组长 Review
↓
通过
↓
合并
这样能避免：
低质量代码进入项目
6.7 Code Review
Review 时重点检查：
代码规范：
命名是否合理
业务逻辑：
实现是否正确
安全问题：
SQL注入
XSS
权限问题
性能问题：
是否存在慢查询
是否存在死循环
6.8 合并功能分支
PR 审核通过后：
合并：
feature/user-login
到：
dev
结果：
dev
├── 登录功能
成功进入开发环境。
6.9 删除功能分支
功能完成后：
删除本地分支：
git branch -d feature/user-login
删除远程分支：
git push origin --delete feature/user-login
保持仓库整洁。
6.10 修复线上 Bug 流程
假设线上发现：
用户登录失败
不能直接在：
dev
修复。
因为：
dev
可能还有未完成功能。
正确做法：
从：
main
创建：
git checkout main
git pull origin main
git checkout -b bugfix/login-password-error
6.11 修复 Bug
修改代码：
修复密码校验逻辑
提交：
git add .
git commit -m "修复登录密码校验Bug"
推送：
git push -u origin bugfix/login-password-error
提交 PR。
6.12 Bug 修复后的合并
首先：
合并到：
main
发布线上。
然后：
同步到：
dev
否则问题还会再次出现。
操作：
git checkout dev
git pull origin dev
git merge bugfix/login-password-error
git push origin dev
最终：
main
修复完成。
dev
同步修复完成。
6.13 Git Flow 完整开发流程
开发新功能：
dev
↓
feature/*
↓
PR
↓
dev
修复线上 Bug：
main
↓
bugfix/*
↓
PR
↓
main
↓
同步到 dev
6.14 团队开发黄金法则
不要直接修改：
main
不要在：
dev
长期开发。
一个功能：
一个 feature 分支
一个 Bug：
一个 bugfix 分支
每天上班第一件事：
git pull
每天下班前：
git push
本课总结
掌握企业 Git Flow：
生产环境：
main
开发环境：
dev
功能开发：
feature/*
Bug修复：
bugfix/*
发布版本：
release/*
开发流程：
git checkout dev
git pull origin dev
git checkout -b feature/user-login
开发代码
git add .
git commit -m "完成登录功能"
git push -u origin feature/user-login
提交 PR
Code Review
合并到 dev
牢记一句话：
main 永远稳定
功能开发走 feature
线上修复走 bugfix
所有代码通过 PR 合并
至此，你已经掌握了企业项目中最常见的 Git 团队协作模式。
下一课《第 7 课：Git 标签（Tag）管理》将学习：
- 什么是 Tag
- 为什么发布版本要打 Tag
- 创建标签
- 查看标签
- 删除标签
- 推送标签
- 企业版本发布规范
- v1.0.0、v2.0.0 的真正含义
