分支类型
在Git工作流中，通常包含以下几种主要的分支类型：
主分支（main/master）
- 存储正式发布的历史
- 包含稳定、可部署的代码
- 通常受保护，需要代码审查才能合并
开发分支（develop）
- 作为功能开发的集成分支
- 包含最新的开发代码
- 用于测试和验证新功能
功能分支（feature）
- 用于开发新功能
- 从develop分支创建
- 完成后合并回develop分支
- 命名规范：feature/功能名称
发布分支（release）
- 用于版本发布准备
- 从develop分支创建
- 只修复bug，不添加新功能
- 命名规范：release/版本号
热修复分支（hotfix）
- 用于修复生产环境的紧急问题
- 从main/master分支创建
- 修复后同时合并到main和develop分支
- 命名规范：hotfix/问题描述
工作流程
1. 功能开发流程
- 从develop分支创建feature分支
- 在feature分支上进行开发
- 完成开发后提交Pull Request
- 代码审查通过后合并到develop分支
- 删除feature分支
2. 版本发布流程
- 从develop分支创建release分支
- 在release分支上进行测试和bug修复
- 测试通过后合并到main/master分支
- 在main/master分支上创建版本标签
- 同时合并回develop分支
- 删除release分支
3. 热修复流程
- 从main/master分支创建hotfix分支
- 在hotfix分支上修复问题
- 修复完成后合并到main/master分支
- 创建新的版本标签
- 同时合并到develop分支
- 删除hotfix分支
最佳实践（精简版）
- 分支命名：
feature/登录页、hotfix/支付回调超时，一眼看出用途；不要用test1、tmp。 - 提交信息：动词开头，一句话说清改了什么（
fix: 修复 iOS 17 深色模式闪退），别写update。 - 保护主分支：GitHub/GitLab 里把
main设为保护分支，禁止直接 push，必须走 PR + review。 - 小步快合：feature 分支活不过一周，越久越难合；每天从 develop rebase 一次，减少冲突。
常见问题
合并冲突
- feature 分支每天 rebase 一次 develop，别攒到最后。
- 冲突文件里
<<<<<<<标记手动处理，改完git add+git rebase --continue。
hotfix 漏合 develop
- hotfix 必须同时合到
main和develop，只合 main 会导致下次发布把修复丢掉。这是最常见的生产事故来源之一。
实战案例：我的分支策略是”按项目规模分级”
我手里几十个仓库，分支策略是三档，ygking-blog 属于最简档：
第一档：个人小项目（ygking-blog、VPSLens 这种博客/文档站）
- 只有一个
master（或 main），直接推，CI 自动部署。 - 改错了？
git revert生成一个反向提交，别reset --push --force——已经推上去的历史，--force会坑掉所有协作者（虽然个人项目没有协作者，但养成习惯）。
第二档：有后端的产品（mecard-go）
main是生产分支，自动部署监听它。- 大功能开
feature/xxx分支，合完就删。有一次我在服务器上直接改代码没提交，自动部署脚本检测到”工作区脏”直接拒绝部署——血的教训：服务器上永远别手改，改完本地 push。
第三档：多人协作（没咋遇到过，备忘）
main+develop+feature/*+hotfix/*，PR 必须 review 才能合。
核心原则就一条：分支数量和项目复杂度成正比。个人博客搞 git-flow，是拿高射炮打蚊子；生产项目裸奔 master，是裸奔。先问”这个项目有几个人、几台机器”，再选模型。
总结
分支策略没有银弹：个人项目一个 master + 自动部署就是最优解；生产项目才需要 develop/release/hotfix 的完整流程。核心原则是分支数量和项目复杂度成正比，别拿高射炮打蚊子，也别裸奔。
