鑫联盟代码分支管理

好的，Git Flow 是一个非常经典且结构清晰的分支模型，特别适用于有计划性版本发布和需要维护多个历史版本的传统软件项目。它由 Vincent Driessen 提出，核心是为不同的任务赋予严格的分支角色。

下图清晰地展示了 Git Flow 的核心分支模型与工作流程：

---

核心分支（永久存在）

分支名	说明
main/master	主分支。存放的是正式发布版的代码，HEAD 永远处于可部署的“生产就绪”状态。所有用户使用的版本都在此分支上有对应的标签。
develop	开发分支。存放的是下一个版本的最终代码，是功能集成的核心分支。平时开发都基于此分支。

辅助分支（临时存在，用完即删）

分支名	命名约定	从哪个分支创建	合并到哪个分支	说明
feature	feature/*	develop	develop	功能分支。用于开发新功能。
release	release/*	develop	develop 和 main	发布分支。用于版本发布的最后准备和修复。
hotfix	hotfix/*	main	develop 和 main	热修复分支。用于快速修复生产环境的紧急 bug。

---

具体工作流程（分步详解）

场景一：开发新功能

假设你要开发一个“用户登录”功能。

1. 创建功能分支：从 develop 分支创建。

   git checkout develop
   git pull origin develop
   git checkout -b feature/user-login

2. 在功能分支上开发：进行多次提交。

   git add .
   git commit -m "feat: add login form"
   # ... 多次提交

3. 完成功能，合并回 develop：

   git checkout develop
   git pull origin develop # 再次更新，避免冲突
   git merge --no-ff feature/user-login # --no-ff 保留分支历史
   git branch -d feature/user-login # 删除本地功能分支
   git push origin develop

场景二：准备发布一个新版本

当 develop 分支的功能足够发布一个版本（如 v1.2.0）时。

1. 创建发布分支：从 develop 分支创建。

   git checkout develop
   git pull origin develop
   git checkout -b release/v1.2.0

2. 在发布分支上操作：

   • 此分支只做 bug 修复，不再添加新功能。
   • 可以更新版本号、编译文件、进行最后的测试。

3. 发布完成，合并到 main 和 develop：

   # 1. 合并到 main，并打上标签
   git checkout main
   git merge --no-ff release/v1.2.0
   git tag -a v1.2.0 -m "Release version 1.2.0"
   git push origin main --tags
   
   # 2. 将发布分支上的修改（可能有的小修复）合并回 develop，避免丢失
   git checkout develop
   git merge --no-ff release/v1.2.0
   
   # 3. 删除发布分支
   git branch -d release/v1.2.0

场景三：修复生产环境的紧急 Bug

生产环境 v1.2.0 发现一个严重 Bug，需要立即修复。

1. 创建热修复分支：从 main 分支上对应的标签创建。

   git checkout main
   git pull origin main
   git checkout -b hotfix/emergency-fix v1.2.0 # 基于标签创建

2. 进行修复并提交。

   git add .
   git commit -m "fix: resolve critical security issue"

3. 修复完成，合并到 main 和 develop：

   # 1. 合并到 main，并创建新标签（小版本号+1，如 v1.2.1）
   git checkout main
   git merge --no-ff hotfix/emergency-fix
   git tag -a v1.2.1 -m "Hotfix for security issue"
   git push origin main --tags
   
   # 2. 将修复同步到 develop 分支，确保后续版本也包含此修复
   git checkout develop
   git merge --no-ff hotfix/emergency-fix
   
   # 3. 删除热修复分支
   git branch -d hotfix/emergency-fix

---

Git Flow 的优缺点

优点	缺点
✅ 流程清晰：每个分支职责明确，易于管理。	❌ 流程复杂：分支类型多，学习成本较高。
✅ 并行开发：功能、发布、修复互不干扰。	❌ 历史复杂：大量的合并提交可能会使提交历史变得复杂。
✅ 版本管理强大：非常适合需要维护多个历史版本的项目。	❌ 不适合持续部署：develop 分支并非始终可发布，与 CI/CD 理念有冲突。
✅ 生产代码稳定：main 分支的代码总是干净的。	❌ 流程繁重：对于小型项目或 Web 应用可能过于沉重。

总结

Git Flow 是一种非常严谨、规范的分支策略，它为软件开发生命周期中的不同阶段（开发、测试、发布、维护）提供了明确的指导。虽然对于追求极致敏捷的团队来说可能显得有些笨重，但对于需要严格控制发布流程和维护多个版本的传统软件项目来说，它依然是一个非常有效和可靠的选择。

微信公众号