Git 分支管理规范

一、大公司的分支管理实践

1. Git Flow（经典模型）

• master：主分支，仅用于发布正式版本
• featureelop：开发分支，集成新功能
• feature/*：功能分支，从 featureelop 分支创建，用于开发新功能
• release/*：发布分支，从 featureelop 分支创建，用于测试和修复
• hotfix/*：热修复分支，从 master 分支创建，用于紧急修复

2. GitHub Flow（持续交付型）

• main：主分支，随时可部署到生产环境
• feature/*：功能分支，从 main 分支创建，开发完成后通过 Pull Request 合并
• hotfix/*：热修复分支，从 main 分支创建，用于紧急修复

3. GitLab Flow（环境驱动型）

• production：生产环境分支，对应线上版本
• staging：预发布分支，用于集成测试
• pre-production：预生产分支，用于最终测试
• feature/*：功能分支，从 staging 分支创建

二、中小团队的分支管理规范

1. 核心分支

• master：主分支，存放稳定、可发布的代码
• test：测试分支，用于集成测试和 Bug 修复
• release/*：发版分支，从 test 分支创建，用于发布前的最终验证

2. 开发分支

• feature/*：开发分支，每个开发人员从 test 分支创建自己的开发分支
  • 命名规范：feature/姓名缩写-功能描述，如 feature/zhangsan-login
  • 开发完成后，通过 Pull Request 合并到 test 分支

📌 分支策略说明

分支类型	命名规范	用途	来源分支
主分支	master	生产环境代码，仅允许通过 release 分支合并。	release/*
测试分支	test	集成所有开发完成的 feature-* 分支，用于测试环境验证。	feature-*
发布分支	release/vX.Y.Z	基于 test 分支创建，用于预发布验证和紧急修复（如 release/v1.0.0）。	test
开发分支	feature-*	开发者个人分支，按姓名缩写-功能描述命名（如 feature/zhangsan-login）。	test

---

🔧 具体操作命令

1. 初始化分支结构（首次设置）

# 从 master 创建测试分支
git checkout master
git pull origin master# 确保本地 master 最新
git checkout -b test# 创建并切换到 test 分支
git push origin test# 推送 test 分支到远程# 从 test 创建第一个发布分支（可选）
git checkout test
git checkout -b release/v1.0.0# 创建发布分支
git push origin release/v1.0.0# 推送到远程

---

2. 开发者日常操作

① 创建个人开发分支（基于 test 分支）

git checkout test
git pull origin test# 拉取最新测试分支代码
git checkout -b feature/zhangsan-login# 创建功能分支（如登录功能）
git push origin feature/zhangsan-login# 推送到远程（可选，便于协作）

② 开发完成后合并到 test 分支

# 在本地 feature 分支完成开发后：
git checkout test
git pull origin test# 确保 test 分支最新
git merge feature/zhangsan-login# 合并功能分支到 test
git push origin test# 推送更新后的 test 分支# 删除已合并的本地 feature 分支（可选）
git branch -d feature/zhangsan-login

---

3. 发布流程

① 从 test 创建发布分支

git checkout test
git pull origin test# 确保 test 分支最新
git checkout -b release/v1.1.0# 创建新发布分支
git push origin release/v1.1.0# 推送到远程

② 发布验证后合并到 master

git checkout master
git pull origin master# 确保 master 最新
git merge release/v1.1.0# 合并发布分支到 master
git tag -a v1.1.0 -m "Release v1.1.0"# 打版本标签
git push origin master --tags# 推送 master 和标签

③ 紧急修复（直接在发布分支处理）

git checkout release/v1.1.0
# 修复代码后提交并推送
git commit -m "fix: 紧急修复XX问题"
git push origin release/v1.1.0# 重新验证后合并到 master（重复步骤②）

---

⚠️ 关键注意事项

1. 分支保护
   • 在 GitHub/GitLab 中设置：
     • master 和 release/* 分支为 Protected，仅允许管理员合并。
     • test 分支允许开发者合并，但需通过 Pull/Merge Request 审核。
2. 命名规范
   • 发布分支用语义化版本号（如 release/v1.0.0），避免混淆。
   • 功能分支统一前缀 feature-*（如 feature-payment）。
3. 冲突解决
   • 所有冲突在 feature-* 或 test 分支解决，禁止直接修改 master 或 release。
4. 定期清理
   • 发布完成后，删除已合并的 feature-* 分支和过时的 release/* 分支。

---

🔄 流程图示

master
│
└── release/v1.0.0 (从 test 创建)│└── test (从 master 创建)│├── feature-login (开发分支)└── feature-payment (开发分支)

---

📚 协作规范建议

• 代码审查：所有合并到 test 或 master 的代码需通过 Pull Request。
• 提交信息：使用规范格式（如 feat: 添加登录功能、fix: 修复支付bug）。
• 自动化工具：结合 CI/CD（如 GitHub Actions）自动部署 test 分支到测试环境。