共计 1345 个字符，预计需要花费 4 分钟才能阅读完成。
简介
随着 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 版本管理策略既适宜周期较长的团队开发，也适宜疾速迭代的开发模式，它整合了其余版本管理策略的长处，能够在麻利开发团队中应用。
麻利开发团队对团队成员的每一位要求比拟高，须要团队成员可能编写自动化测试脚本，也须要团队中的每一位成员都可能独立合并本人的代码。
关注微信公众号【技术治理修行】
程序员职业生涯规划，分享程序员进阶架构师所需全副技能，分享程序员如何转治理做技术总监、CTO，分享程序员如何转行产品经理、项目经理
