简介

随着Git的普及，为了更高效地进行团队协作开发，人们通过经验总结研究出了几套适用于各种团队和项目的分支管理策略，上篇文章我们讲解了 Git Flow 代码版本管理策略，它对版本控制较为严格，主要适合开发团队规模较大、开发周期较长，可达几周至几个月的项目，同时，文章提供了版本管理方案图及必要的讲解。

接下来将介绍Git 分支管理策略：TBD++ Flow，该版本管理策略整合了其他策略的优点，适合敏捷开发团队，开发周期长、快速迭代均适用。先看一下工作流图。

TBD++ Flow 工作流图

TBD++ Flow 工作流说明

总体规范建议：

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

1. 主分支 Master

稳定版本代码分支，不能在此分支直接修改代码， 只接受 hotfix、release 分支的代码合并，每次从 release/hotfix 分支合并必须打版本号 tag，以方便后续的代码追溯。该分支上部署自动化测试脚本，在每次代码提交至该分支后都会触发测试，以此保证主分支核心功能的稳定。

2.新功能分支 Feature

新功能迭代开发分支，开发人员在此分支进行编码及代码评审->测试人员进行功能测试->开发人员修复bug->从 master 分支拉取最新代码 ->将测试通过后的代码合并到 master。feature 分支需要定期向 master 分支拉取最新代码。

3.发布分支 Release

feature 分支经过代码评审及功能测试后合并到 develop 分支，测试人员再从 master 分支拉取对应的 release 分支。测试部进行集成测试、开发部修改 bug、产品验收。产品验收通过后（发布上线前）基于 release 分支打 tag 进行版本发布，再将代码合并回 master分支，如果代码较为关键，还需要合并到其他的 release 分支。最后可将 feature 迭代分支删除。

4.热修复分支 HotFix

该分支分为两种情况：

1）如果是在 master 分支发现的bug，则该分支基于 master 创建，bug 修复完成并测试通过后需要合并回 master 分支。

2）如果是在 release 分支发现的bug，则该分支基于 release 发布时的 tag 版本创建，bug 修复完成并测试通过后需要合并回 master 分支、所有涉及的 release 分支以及 master 分支。最后在 release 分支上添加新的 tag。

总结

以上是敏捷项目团队中所推荐的 Git 版本管理策略，我们可以看到上述策略比前文的 Git Flow 简单了许多，少了一个主要的 develop 分支，只需要维护 master 一个主干分支，现代的开发模式中，为更快更好地满足客户的需求，往往采用敏捷迭代的开发方式，TBD++Flow 版本管理策略即适合周期较长的团队开发，也适合快速迭代的方式，它整合了其他版本管理策略的优点，推荐在敏捷开发团队中使用。

敏捷开发团队对团队成员的每一位要求比较高，需要团队成员能够编写自动化测试脚本，也需要团队中的每一位成员都能够独立合并自己的代码。