Git分支管理：每个分支为什么这么命名？
一、为什么需要分支策略？
避免代码冲突：多人同时开发时隔离代码
保证主分支稳定：随时可部署的干净代码
灵活管理功能：并行开发多个功能模块
快速修复问题：紧急Bug修复不影响主流程
二、核心分支类型
1. 🌲 主分支（master/main）
作用：正式环境运行的稳定代码
规则：
唯一且受保护（只有管理员能合并）
每次合并必须通过测试
不允许任何⼈推送，只允许仓库管理员合并
生命周期：永久存在
2. 🚧 开发分支（develop）
作用：集成所有功能的测试版本
规则：
基于master分支创建
同样设置为保护分支
用于部署到测试环境
生命周期：永久存在
3. ✨ 功能分支（feature/*）
作用：开发新功能/需求
命名：
feature/功能名（如feature/user-login）规则：
从develop分支创建
完成新功能/需求开发后，开发⼈员提交feature分⽀到develop分⽀的 Pull Request，技术负责⼈（仓库管理员）进⾏审核决定是否将 feature 分⽀合⼊develop分⽀
合并后立即删除
生命周期：功能开发期间（通常1-3天）
4. 🐛 Bug修复分支（bug/*）
作用：修复线上或测试环境问题
命名：
bug/问题描述（如bug/login-error）规则：
线上问题：从master分支创建
测试问题：从develop分支创建
修复后合并到对应分支并删除
生命周期：问题修复期间（通常几小时）
三、标准工作流程
从master创建develop分支
开发新功能时：
从develop创建feature分支
开发完成后提交Pull Request(PR)
管理员审核后合并到develop
develop部署到测试环境
测试通过后合并到master
从master发布线上版本
详细的来说就是
1.将master 分⽀设置为保护分⽀（不允许任何⼈推送，只允许仓库管理员合并）。2. 基于master分⽀创建develop 分⽀，并设置为保护分⽀。3. 开发⼈员开发新功能/需求时基于 develop 分⽀创建 feature 分⽀，并在该分⽀上完成新功能的代
码开发。4. 完成新功能/需求开发后，开发⼈员提交feature分⽀到develop分⽀的 Pull Request，技术负责
⼈（仓库管理员）进⾏审核决定是否将 feature 分⽀合⼊develop 分⽀。5. 审核未通过，处理pull request中存在的问题。审核通过合并后将 develop 分⽀部署到测试环
境，提供给测试⼈员进⾏测试。6. 循环3-5步骤，直到项⽬完成。7. 将测试完成的 develop 分⽀合并到 master 分⽀上，基于 master 分⽀进⾏线上环境发布。8. 项⽬测试环节如果发现bug，基于develop分⽀创建新分⽀修改bug，修改完成后合⼊develop分
⽀进⾏测试。然后再执⾏步骤7。9. 线上环境发现bug，基于master分⽀创建新分⽀修改bug，修改完成后直接部署bug分⽀到测试
环境进⾏测试。测试通过后合⼊master分⽀，基于 master 分⽀进⾏线上环境发布。四、遇到Bug怎么办？
场景1：测试环境发现Bug
从develop创建bug分支
修复后合并回develop
重新测试验证
场景2：线上环境发现Bug
从master创建bug分支
修复后直接部署测试
测试通过后合并到master
立即发布线上热修复
五、必须遵守的黄金法则
🔒 保护分支：master和develop必须设为保护分支
🧹 及时清理：feature/bug分支合并后立即删除
🔄 频繁同步：每天从develop更新本地分支
✏️ 规范命名：使用
feature/xxxbug/xxx格式👁️ 代码审查：所有合并必须通过PR审核
六、为什么这样设计？
master绝对稳定：随时可应对线上紧急问题
develop持续集成：快速验证新功能兼容性
功能隔离开发：避免半成品代码影响他人
历史记录清晰：通过分支名直接追溯修改目的