my-git

腾讯云社区 Gitflow 分支规范实践

原文链接：

• git 分支管理和工作流规范：具体规范

1. 这类规范解决什么问题

很多团队真正的问题通常是分支语义不清：

• master 到底是不是线上版本
• develop 里有没有未上线代码
• release 分支能不能继续加功能
• hotfix 修完后要回合到哪里
• feature 分支什么时候删除

Gitflow 的价值就在于把这些角色说清楚，特别适合发版周期明确、上线窗口固定、测试周期较长的团队。

2. 分支角色

分支	作用
master / main	与线上生产版本保持一致
develop	日常开发集成分支
feature/*	功能开发分支
release/*	特定版本测试和发布准备
hotfix/*	线上紧急问题修复

基本约定是：不要直接修改主线和开发集成分支，功能、发布、修复都通过对应分支完成。

3. 常规开发流程

develop -> feature/x -> develop -> release/1.2.0 -> main -> tag

操作含义：

1. 从 develop 创建 feature/x
2. 功能完成后合回 develop
3. 一批功能准备提测时，从 develop 创建 release/*
4. 测试阶段的问题直接修在 release/*
5. 发布完成后，release/* 合入 main 并打 tag
6. 同时把 release/* 的修复回合到 develop

4. Hotfix 流程

线上问题优先从生产基线创建 hotfix/*：

main -> hotfix/1.2.1 -> main -> tag
                    \-> develop

关键点：

• hotfix 只做最小修复
• 发布后必须打 tag
• 修复必须回合到 develop
• 如果还存在活跃 release 分支，也要评估是否需要同步

5. 常见特殊情况

develop 里已有未上线代码，但要紧急上线一个小功能

这时不要直接从 develop 拉分支，因为它可能带出不该上线的内容。

更稳的做法是从 main 或生产 tag 创建分支，完成后按 hotfix 或紧急 release 的方式发布，再把变更同步回 develop。

两个 feature 开发到一半发现强依赖

最好在需求拆分阶段提前识别依赖。

如果已经拆开，团队要尽快决定合并为一个 feature 分支，或者明确一个公共基础分支，避免两个分支长期互相 cherry-pick。

rebase 的边界

本地整理提交可以使用 rebase。

一旦分支已经发布到公共仓库，尤其已有其他人基于它继续开发，就不要随意 rebase 后强推。

6. 适合什么团队

适合：

• 客户端、SDK、企业交付产品
• 需要发版测试周期
• 需要维护多个版本线
• 线上 hotfix 要有明确路径

不适合：

• 每天多次发布的 Web 服务
• 团队很小，发布非常轻
• CI/CD 成熟，主线随时可发布

7. 对本仓库的启发

Gitflow 的重点是约束：

• 哪些分支代表生产事实
• 哪些分支可以接收新功能
• 哪些分支只能修 bug
• 发版后变更如何回合
• tag 如何对应线上版本

如果团队采用 Gitflow，最好把这些规则写进团队规范，并用分支保护、PR 模板、CI 检查减少人工遗漏。

This site is open source. Improve this page.