简介
在团队合作开发中，版本管理工具尤为重要，它能够帮忙团队很好地进行代码的共享、回滚等操作，比拟风行的版本管理工具有：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 策略只适宜团队规模较大，我的项目开发周期较长的我的项目，这个周期能够是几周至几个月，而古代的开发模式中，为更快更好地满足客户的需要，往往采纳麻利迭代的开发方式。
接下来，我将更新一篇适宜麻利治理团队的版本管理策略，供大家参考。
关注微信公众号
程序员职业生涯规划，分享程序员进阶架构师所需全副技能，分享程序员如何转治理做技术总监、CTO，分享程序员如何转行产品经理、项目经理