适合人群前端/后端开发者、技术团队负责人## 写在前面你是否遇到过这些问题- 多人协作时代码冲突频繁不知道该在哪个分支开发- 线上突然出现紧急 bug但开发分支还有未完成的功能不敢直接发布- 版本管理混乱想回退到某个稳定版本却找不到如果你有以上困扰那么 **Git Flow** 工作流将是你的救星。它是一套成熟的分支管理规范被无数团队验证有效。今天我将用最通俗易懂的方式带你彻底掌握 Git Flow。---## 一、Git Flow 核心5 种分支 1 个标签在 Git Flow 中我们将代码分为 **5 种分支** 和 **1 种标签**每种都有明确的职责| 分支/标签 | 用途 | 生命周期 | 备注 ||----------|------|---------|------|| **master** | 生产环境线上版本 | 永久存在 | 始终保持稳定只接受 release 和 hotfix 合并 || **develop** | 日常开发集成测试环境 | 永久存在 | 所有新功能都先合并到这里 || **feature/*** | 功能开发分支 | 临时分支 | 从 develop 分出开发完成后合并回 develop || **release/*** | 预发布分支 | 临时分支 | 从 develop 分出只修 bug不加新功能 || **hotfix/*** | 紧急修复分支 | 临时分支 | 从 master 分出修复线上 bug 后合并回 master 和 develop || **tags** | 版本标签 | 永久存在 | 标记每个正式发布的版本方便回溯 |### 分支关系图解master (生产) ●────────●────────●────────●↑ ↑ ↑│ │ │release (预发) │ ●───┴───● ││ ↑ │ ││ │ │ │develop (开发) ●────●───●───●────●───●───●↑ ↑ ↑ ↑│ │ │ │feature (功能) ●───● ●───●---## 二、日常开发在 feature 分支上工作### 场景你要开发 2.3.0 版本的新功能#### 步骤 1创建功能分支bash# 1. 切换到 develop 分支git checkout develop# 2. 拉取最新代码重要避免基于旧代码开发git pull# 3. 创建功能分支命名规范feature/版本号git checkout -b feature/2.3.0# 4. 推送到远程仓库git push -u origin feature/2.3.0** 命名建议**- feature/2.3.0按版本号- feature/user-login按功能名- feature/20260427-payment按日期功能#### 步骤 2本地开发bash# 修改代码后...# 1. 添加到暂存区git add .# 2. 提交commit 信息要清晰git commit -m feat: 完成用户登录功能# 3. 推送到远程git push** Commit 信息规范**- feat: 新功能- fix: 修复 bug- docs: 文档更新- style: 代码格式调整- refactor: 重构代码#### 步骤 3清理旧分支可选开发新版本前可以删除已合并的旧分支bash# 删除本地分支git branch -d feature/2.2.0# 删除远程分支git push origin --delete feature/2.2.0---## 三、功能集成合并到 develop### 场景feature/2.3.0 开发完成需要集成到测试环境bash# 1. 切换到 develop 分支git checkout develop# 2. 拉取最新代码git pull# 3. 合并功能分支git merge feature/2.3.0# 4. 推送到远程触发测试环境部署git push**⚠️ 注意事项**- 合并前先在 feature 分支自测通过- 如果有冲突优先和功能负责人沟通- 合并后通知测试团队进行集成测试---## 四、预发布创建 release 分支### 场景所有功能开发完毕准备上线#### 步骤 1创建 release 分支bash# 1. 切换到 develop 分支git checkout developgit pull# 2. 创建 release 分支命名规范release/版本号git checkout -b release/2.3.0# 3. 推送到远程git push -u origin release/2.3.0#### 步骤 2预发布期间修 Bug**重要原则release 分支只修 bug不加新功能**bash# 1. 在 release 分支修改代码git checkout release/2.3.0# 2. 提交修复git add .git commit -m fix: 修复预发布阶段发现的登录buggit push** 为什么不在 develop 修**- develop 可能还在开发下一个版本的功能- release 分支是版本冻结状态只关注当前版本质量---## 五、正式发布合并到 master 并打 Tag### 场景预发布测试通过准备上线bash# 1. 切换到 master 分支git checkout mastergit pull# 2. 合并 release 分支git merge release/2.3.0# 3. 打 Tag 标记版本重要git tag -a v2.3.0 -m Release version 2.3.0# 4. 推送 master 和 Taggit pushgit push origin v2.3.0** Tag 的作用**- 标记每个正式发布的版本- 方便快速回退到某个稳定版本- 便于追溯历史版本---## 六、紧急修复hotfix 分支救场### 场景线上突然出现严重 bug需要立即修复#### 步骤 1创建 hotfix 分支bash# 1. 从 master 分支创建 hotfixgit checkout mastergit pullgit checkout -b hotfix/fix-critical-bug# 2. 推送到远程git push -u origin hotfix/fix-critical-bug#### 步骤 2修复并发布bash# 1. 修改代码git add .git commit -m hotfix: 修复线上支付失败问题git push# 2. 合并到 mastergit checkout mastergit merge hotfix/fix-critical-bug# 3. 打新 Tag版本号递增git tag v2.3.1git pushgit push --tags#### 步骤 3同步到 develop关键**千万别忘记这一步** 否则下次发布会把 bug 带回来。bash# 1. 切换到 developgit checkout developgit pull# 2. 合并 hotfixgit merge hotfix/fix-critical-buggit push---## 七、版本管理Tag 的高级用法### 1. 查看所有 Tagbashgit tag### 2. 创建带注释的 Tagbash# -a 表示 annotated tag推荐git tag -a v2.3.0 -m Release version 2.3.0: 新增用户登录功能# 推送到远程git push origin v2.3.0### 3. 删除 Tagbash# 删除本地 Taggit tag -d v2.3.0# 删除远程 Taggit push origin :refs/tags/v2.3.0### 4. 回滚到某个 Tagbash# 查看某个 Tag 的代码只读模式git checkout tags/v2.3.0# 基于 Tag 创建新分支git checkout -b hotfix/rollback-v2.3.0 tags/v2.3.0---## 八、完整工作流示例假设你是团队开发者完整走一遍 Git Flow### 阶段 1开发新功能第 1 周bashgit checkout developgit pullgit checkout -b feature/user-profile# ... 开发代码 ...git add .git commit -m feat: 完成用户资料页git push### 阶段 2集成测试第 2 周bashgit checkout developgit merge feature/user-profilegit push# 测试团队在测试环境验证### 阶段 3预发布第 3 周bashgit checkout developgit checkout -b release/2.3.0git push -u origin release/2.3.0# 预发布环境测试发现 bug 后修复git add .git commit -m fix: 修复头像上传失败git push### 阶段 4正式发布第 3 周末bashgit checkout mastergit merge release/2.3.0git tag v2.3.0git pushgit push --tags# 同步到 developgit checkout developgit merge release/2.3.0git push### 阶段 5紧急修复第 4 周bash# 线上发现支付 buggit checkout mastergit checkout -b hotfix/payment-fix# ... 修复代码 ...git add .git commit -m hotfix: 修复支付金额计算错误git push# 发布git checkout mastergit merge hotfix/payment-fixgit tag v2.3.1git push --tags# 同步到 developgit checkout developgit merge hotfix/payment-fixgit push---## 九、常见问题 QA### Q1feature 分支可以直接合并到 master 吗**不可以** 必须先合并到 develop 测试再通过 release 分支发布到 master。### Q2多个 feature 分支可以同时开发吗**可以** 这正是 Git Flow 的优势每个功能独立开发互不影响。### Q3release 分支的 bug 修复需要合并回 develop 吗**需要** 发布后执行bashgit checkout developgit merge release/2.3.0git push### Q4hotfix 为什么要同时合并到 master 和 develop- 合并到 **master**立即修复线上问题- 合并到 **develop**防止下次发布时 bug 复现### Q5Tag 和分支有什么区别- **分支**可以继续提交代码是活的- **Tag**只是一个快照标记是死的用于标记版本---## 十、团队协作最佳实践### 1. 分支命名规范feature/版本号-功能名 # feature/2.3.0-loginrelease/版本号 # release/2.3.0hotfix/问题描述 # hotfix/fix-payment-bug### 2. Commit 信息规范feat: 新功能fix: 修复 bugdocs: 文档更新style: 代码格式refactor: 重构test: 测试相关chore: 构建工具或辅助工具变动### 3. 合并前检查清单- [ ] 代码已自测通过- [ ] 已拉取最新代码git pull- [ ] 已解决所有冲突- [ ] Commit 信息清晰- [ ] 已通知相关人员### 4. 保护分支设置在 GitHub/GitLab 设置中- **master**只允许 release 和 hotfix 合并需要 Code Review- **develop**只允许 feature 合并需要至少 1 人审核- **feature**开发者自由提交---## 写在最后Git Flow 看似复杂但掌握后会发现它的逻辑非常清晰- **develop**日常开发的主战场- **feature**每个功能的独立空间- **release**上线前的质量把关- **master**永远稳定的生产环境- **hotfix**紧急情况的救命稻草- **tags**版本历史的时光机建议团队制定一份 **Git Flow 规范文档**新人入职时培训确保所有人遵循同一套流程。如果这篇文章对你有帮助欢迎点赞、在看、转发有任何问题欢迎在评论区留言交流。---**推荐阅读**- 《Git 进阶如何优雅地解决代码冲突》- 《前端工程化实践从 0 到 1 搭建团队规范》- 《Code Review 最佳实践提升代码质量的 10 个技巧》---
适合人群前端/后端开发者、技术团队负责人## 写在前面你是否遇到过这些问题- 多人协作时代码冲突频繁不知道该在哪个分支开发- 线上突然出现紧急 bug但开发分支还有未完成的功能不敢直接发布- 版本管理混乱想回退到某个稳定版本却找不到如果你有以上困扰那么 **Git Flow** 工作流将是你的救星。它是一套成熟的分支管理规范被无数团队验证有效。今天我将用最通俗易懂的方式带你彻底掌握 Git Flow。---## 一、Git Flow 核心5 种分支 1 个标签在 Git Flow 中我们将代码分为 **5 种分支** 和 **1 种标签**每种都有明确的职责| 分支/标签 | 用途 | 生命周期 | 备注 ||----------|------|---------|------|| **master** | 生产环境线上版本 | 永久存在 | 始终保持稳定只接受 release 和 hotfix 合并 || **develop** | 日常开发集成测试环境 | 永久存在 | 所有新功能都先合并到这里 || **feature/*** | 功能开发分支 | 临时分支 | 从 develop 分出开发完成后合并回 develop || **release/*** | 预发布分支 | 临时分支 | 从 develop 分出只修 bug不加新功能 || **hotfix/*** | 紧急修复分支 | 临时分支 | 从 master 分出修复线上 bug 后合并回 master 和 develop || **tags** | 版本标签 | 永久存在 | 标记每个正式发布的版本方便回溯 |### 分支关系图解master (生产) ●────────●────────●────────●↑ ↑ ↑│ │ │release (预发) │ ●───┴───● ││ ↑ │ ││ │ │ │develop (开发) ●────●───●───●────●───●───●↑ ↑ ↑ ↑│ │ │ │feature (功能) ●───● ●───●---## 二、日常开发在 feature 分支上工作### 场景你要开发 2.3.0 版本的新功能#### 步骤 1创建功能分支bash# 1. 切换到 develop 分支git checkout develop# 2. 拉取最新代码重要避免基于旧代码开发git pull# 3. 创建功能分支命名规范feature/版本号git checkout -b feature/2.3.0# 4. 推送到远程仓库git push -u origin feature/2.3.0** 命名建议**- feature/2.3.0按版本号- feature/user-login按功能名- feature/20260427-payment按日期功能#### 步骤 2本地开发bash# 修改代码后...# 1. 添加到暂存区git add .# 2. 提交commit 信息要清晰git commit -m feat: 完成用户登录功能# 3. 推送到远程git push** Commit 信息规范**- feat: 新功能- fix: 修复 bug- docs: 文档更新- style: 代码格式调整- refactor: 重构代码#### 步骤 3清理旧分支可选开发新版本前可以删除已合并的旧分支bash# 删除本地分支git branch -d feature/2.2.0# 删除远程分支git push origin --delete feature/2.2.0---## 三、功能集成合并到 develop### 场景feature/2.3.0 开发完成需要集成到测试环境bash# 1. 切换到 develop 分支git checkout develop# 2. 拉取最新代码git pull# 3. 合并功能分支git merge feature/2.3.0# 4. 推送到远程触发测试环境部署git push**⚠️ 注意事项**- 合并前先在 feature 分支自测通过- 如果有冲突优先和功能负责人沟通- 合并后通知测试团队进行集成测试---## 四、预发布创建 release 分支### 场景所有功能开发完毕准备上线#### 步骤 1创建 release 分支bash# 1. 切换到 develop 分支git checkout developgit pull# 2. 创建 release 分支命名规范release/版本号git checkout -b release/2.3.0# 3. 推送到远程git push -u origin release/2.3.0#### 步骤 2预发布期间修 Bug**重要原则release 分支只修 bug不加新功能**bash# 1. 在 release 分支修改代码git checkout release/2.3.0# 2. 提交修复git add .git commit -m fix: 修复预发布阶段发现的登录buggit push** 为什么不在 develop 修**- develop 可能还在开发下一个版本的功能- release 分支是版本冻结状态只关注当前版本质量---## 五、正式发布合并到 master 并打 Tag### 场景预发布测试通过准备上线bash# 1. 切换到 master 分支git checkout mastergit pull# 2. 合并 release 分支git merge release/2.3.0# 3. 打 Tag 标记版本重要git tag -a v2.3.0 -m Release version 2.3.0# 4. 推送 master 和 Taggit pushgit push origin v2.3.0** Tag 的作用**- 标记每个正式发布的版本- 方便快速回退到某个稳定版本- 便于追溯历史版本---## 六、紧急修复hotfix 分支救场### 场景线上突然出现严重 bug需要立即修复#### 步骤 1创建 hotfix 分支bash# 1. 从 master 分支创建 hotfixgit checkout mastergit pullgit checkout -b hotfix/fix-critical-bug# 2. 推送到远程git push -u origin hotfix/fix-critical-bug#### 步骤 2修复并发布bash# 1. 修改代码git add .git commit -m hotfix: 修复线上支付失败问题git push# 2. 合并到 mastergit checkout mastergit merge hotfix/fix-critical-bug# 3. 打新 Tag版本号递增git tag v2.3.1git pushgit push --tags#### 步骤 3同步到 develop关键**千万别忘记这一步** 否则下次发布会把 bug 带回来。bash# 1. 切换到 developgit checkout developgit pull# 2. 合并 hotfixgit merge hotfix/fix-critical-buggit push---## 七、版本管理Tag 的高级用法### 1. 查看所有 Tagbashgit tag### 2. 创建带注释的 Tagbash# -a 表示 annotated tag推荐git tag -a v2.3.0 -m Release version 2.3.0: 新增用户登录功能# 推送到远程git push origin v2.3.0### 3. 删除 Tagbash# 删除本地 Taggit tag -d v2.3.0# 删除远程 Taggit push origin :refs/tags/v2.3.0### 4. 回滚到某个 Tagbash# 查看某个 Tag 的代码只读模式git checkout tags/v2.3.0# 基于 Tag 创建新分支git checkout -b hotfix/rollback-v2.3.0 tags/v2.3.0---## 八、完整工作流示例假设你是团队开发者完整走一遍 Git Flow### 阶段 1开发新功能第 1 周bashgit checkout developgit pullgit checkout -b feature/user-profile# ... 开发代码 ...git add .git commit -m feat: 完成用户资料页git push### 阶段 2集成测试第 2 周bashgit checkout developgit merge feature/user-profilegit push# 测试团队在测试环境验证### 阶段 3预发布第 3 周bashgit checkout developgit checkout -b release/2.3.0git push -u origin release/2.3.0# 预发布环境测试发现 bug 后修复git add .git commit -m fix: 修复头像上传失败git push### 阶段 4正式发布第 3 周末bashgit checkout mastergit merge release/2.3.0git tag v2.3.0git pushgit push --tags# 同步到 developgit checkout developgit merge release/2.3.0git push### 阶段 5紧急修复第 4 周bash# 线上发现支付 buggit checkout mastergit checkout -b hotfix/payment-fix# ... 修复代码 ...git add .git commit -m hotfix: 修复支付金额计算错误git push# 发布git checkout mastergit merge hotfix/payment-fixgit tag v2.3.1git push --tags# 同步到 developgit checkout developgit merge hotfix/payment-fixgit push---## 九、常见问题 QA### Q1feature 分支可以直接合并到 master 吗**不可以** 必须先合并到 develop 测试再通过 release 分支发布到 master。### Q2多个 feature 分支可以同时开发吗**可以** 这正是 Git Flow 的优势每个功能独立开发互不影响。### Q3release 分支的 bug 修复需要合并回 develop 吗**需要** 发布后执行bashgit checkout developgit merge release/2.3.0git push### Q4hotfix 为什么要同时合并到 master 和 develop- 合并到 **master**立即修复线上问题- 合并到 **develop**防止下次发布时 bug 复现### Q5Tag 和分支有什么区别- **分支**可以继续提交代码是活的- **Tag**只是一个快照标记是死的用于标记版本---## 十、团队协作最佳实践### 1. 分支命名规范feature/版本号-功能名 # feature/2.3.0-loginrelease/版本号 # release/2.3.0hotfix/问题描述 # hotfix/fix-payment-bug### 2. Commit 信息规范feat: 新功能fix: 修复 bugdocs: 文档更新style: 代码格式refactor: 重构test: 测试相关chore: 构建工具或辅助工具变动### 3. 合并前检查清单- [ ] 代码已自测通过- [ ] 已拉取最新代码git pull- [ ] 已解决所有冲突- [ ] Commit 信息清晰- [ ] 已通知相关人员### 4. 保护分支设置在 GitHub/GitLab 设置中- **master**只允许 release 和 hotfix 合并需要 Code Review- **develop**只允许 feature 合并需要至少 1 人审核- **feature**开发者自由提交---## 写在最后Git Flow 看似复杂但掌握后会发现它的逻辑非常清晰- **develop**日常开发的主战场- **feature**每个功能的独立空间- **release**上线前的质量把关- **master**永远稳定的生产环境- **hotfix**紧急情况的救命稻草- **tags**版本历史的时光机建议团队制定一份 **Git Flow 规范文档**新人入职时培训确保所有人遵循同一套流程。如果这篇文章对你有帮助欢迎点赞、在看、转发有任何问题欢迎在评论区留言交流。---**推荐阅读**- 《Git 进阶如何优雅地解决代码冲突》- 《前端工程化实践从 0 到 1 搭建团队规范》- 《Code Review 最佳实践提升代码质量的 10 个技巧》---
