简介

在团队协作开发中，版本管理工具尤为重要，它可以帮助团队很好地进行代码的共享、回滚等操作，比较流行的版本管理工具有：CVS、SVN、Git。Git作为分布式版本管理工具，优势十分明显，它可以为每位团队成员本地提供一套完整的代码库，这使得开发者可以在无网的情况下将代码提交至本地仓库，减少了对中心服务器的依赖。

随着Git的普及，为了更高效地进行团队协作开发，人们通过经验总结研究出了几套适用于各种团队和项目的分支管理策略，Git Flow 就是其中之一，它对版本控制更为严格，主要适合开发团队规模较大、开发周期较长，可达几周至几个月的项目。接下来，直接展示最终实战方案，如果开发团队和项目类型适合，可直接拿来使用。

Git Flow 工作流图

Git Flow 工作流说明

总体规范建议：

统一以版本号命名，各分支以版本号对应，比如，feature/v1.0 、release/v1.0、tag/v1.0

1. 主分支 Master

稳定版本代码分支，不能在此分支直接修改代码， 只接受 hotfix、release 分支的代码合并，每次从 release/hotfix 分支合并必须打版本号 tag，以方便后续的代码追溯。

2.主开发分支 Develop

每个feature迭代从 develop 拉取分支，该分支只接受 hotfix、release 分支的代码合并，该分支禁止直接合并到 master。

3.新功能分支 Feature

新功能迭代开发分支，开发人员开发完成后合并生成预发布分支 release/xxx（与 feature 分支一一对应），此分支禁止测试、禁止发布上线、禁止直接合并到 develop、禁止直接合并到 master。

4.预发布分支 Release

feature 分支由开发自测完成后合并到 develop 分支，测试人员再从 develop 分支新建对应的 release 分支。测试部进行集成测试、开发部修改 bug、产品验收。测试通过后（发布上线前）将此分支合并到 develop 和 master 分支，然后可将 release 迭代和对应的 feature 迭代分支删除。

5.热修复分支 HotFix

该分支基于 master 分支创建，用于修改线上发现的紧急 bug， bug 修复完成并测试通过后需要合并回 master 和 develop 分支。

总结

以上是真实项目中的 Git 版本管理策略，其经过了实战的考验，可以拿来即用，我们可以看到上述策略较为繁琐，需要同时维护 master 和 develop 两个主要分支，因此，Git Flow 策略只适合团队规模较大，项目开发周期较长的项目，这个周期可以是几周至几个月，而现代的开发模式中，为更快更好地满足客户的需求，往往采用敏捷迭代的开发方式。

接下来，我将更新一篇适合敏捷管理团队的版本管理策略，供大家参考。