Git Flow 分支策略规范

本文档用于规范团队 Git 分支命名、开发流程、紧急发布/回滚处理等操作，支持多主线开发及紧急场景处理。

一、分支类型说明

二、分支命名规范

三、功能开发流程（正常流程）

1. 从 master 创建开发分支

git checkout master
git pull origin master
git checkout -b develop/<模块>-<功能>

2. 提交代码回 develop

git add .
git commit -m "feat: 实现 <模块> 的 <功能>"
git push develop**

四、迭代区分策略（多版本开发）

• 当存在多个版本/重构/独立项目并行时，应以 develop/2.0、develop/refactor-x 等区分；
• 避免将所有开发堆积在一个 develop 分支中，避免冲突和混乱。

五、发布流程（常规上线）

1. 从 develop 合并到 release 分支

git checkout develop/**
git pull origin develop/**
git checkout release
git pull origin release
git merge --no-ff develop/**

2. 测试并修复 bug

在 release 分支中提交 bugfix 或微调，不影响开发主干。

3. 合并 release 到 master，并打 Tag

git checkout master
git pull origin master
git merge --no-ff release/v1.3.0
git tag -a v1.3.0 -m "Release v1.3.0"

六、测试环境部署说明

• 所有测试部署均基于 release/* 分支；
• 不单独创建 test 分支；
• 如需多个版本同时测试，可创建多个 release 分支并分别部署。

七、紧急功能发布流程

1. 从 master 创建临时功能分支

git checkout master
git pull origin master
git checkout -b feature/urgent-xxx

2. 开发并合并回 master（跳过 release）

git add .
git commit -m "feat: 紧急上线功能 xxx"
git checkout master
git merge --no-ff feature/urgent-xxx
git tag -a v1.3.2 -m "紧急上线功能 v1.3.2"

3. 将 master 的更新同步回 develop

git checkout develop**
git pull origin develop**
git merge --no-ff master

✅ 注意：务必同步 master → develop，防止功能丢失或回滚时丢失记录。

八、紧急修复流程（hotfix）

1. 从 master 创建 hotfix 分支

git checkout master
git pull origin master
git checkout -b hotfix/v1.3.3

2. 修复 bug 并合并

git add .
git commit -m "fix: 修复线上问题 xxx"
git checkout master
git merge --no-ff hotfix/v1.3.3
git tag -a v1.3.3 -m "Hotfix v1.3.3"

3. 合并回 develop，保持一致

git checkout develop
git merge --no-ff hotfix/v1.3.3
git branch -d hotfix/v1.3.3

九、版本回滚策略

方式一：重置版本至历史 Tag（适用于紧急回滚）

git checkout master
git reset --hard v1.3.0
git push origin master --force

⚠️ 警告：会造成历史记录回退，仅适用于极端情况。

方式二：撤销指定提交（使用 git revert）

git checkout master
git revert <commit_hash>
git push origin master

十、部署策略建议

十一、最佳实践建议

• 所有合并操作均使用 --no-ff 保留提交记录；
• 使用 Pull Request/Merge Request 统一审核流程；
• 主干分支（master/develop）设置为受保护分支；
• 所有正式版本打 Tag 标记版本；

十二、常用命令速查表