现代软件开发过程中要实现高效的团队协作，需要使用代码分支管理工具实现代码的共享、追溯、回滚及维护等功能。目前流行的代码管理工具，包括CVS，SVN，Git，Mercurial等。相比CVS和SVN的集中管理，Git具有非常明显的优势，例如：去中心化的代码管理方式减少了开发者对中心服务器的依赖，每个成员在本地都有一个完整的代码库，在不联网的情况下也能提交代码；不同于SVN中的每个分支具有独立的代码，Git中的每一个分支只是指向当前版本的一个指针，Git的分支策略使创建和合并分支变得快捷灵活。
在使用Git管理代码以及多人协作的开发模式下，一个团队甚至一个公司对Git的使用有统一规范的工作流程尤为重要，开发团队遵循统一的规则执行功能开发，问题修复，分支合并，版本迭代及发布等操作，可以使团队合作变得平滑顺畅，项目有序向前推进，我们把组织内这样的工作流程（workflow）称为Git代码分支管理模型，本文将介绍几个主流的git代码分支管理模型：
Git flow
Git flow是由Vincent Driessen于2010 年提出的代码分支管理模型，但是不要被名字欺骗了，git-flow并不是Git社区官方推荐的工作流。
Git flow存在两个长期的独立分支：主分支master和开发分支develop，主分支用于版本发布，主分支的每个版本都是质量稳定和功能齐全的发布版。开发分支用于日常开发工作，存放最新的开发版代码。当开发分支的代码达到稳定状态并可以发布版本时，代码需要被合并到 master 分支，然后标记上对应的版本标签（tag）。
GitHub flow
GitHub flow是由Scott Chacon于2011年提出的代码分支管理模型，这是GitHub官方推荐的开发流程，以快速部署为目标，目前大部分开源项目都遵循这一流程。
Github flow最大的特点是只有一个长期分支，即主分支master，且主分支始终保持可发布状态。从master上创建新分支进行功能开发、问题修复等，这些分支通过pull request将代码合并到master。为了保证主分支的代码质量，master的权限只开放给一部分人。Pull request是请求别人pull你的代码库（repository），也就是把开发分支的代码经过代码评审并通过测试后，让有权限的管理员合并回master。
GitLab flow
GitLab flow是由GitLab 的 CEO Sytse Sijbrandij 于 2014 年正式发布的代码分支管理模型，属于GitHub flow的演进版本，与GitHub相同之处是也存在一个长期主分支mater，从master上创建新分支进行功能开发、问题修复等，结束后合并回master。与GitHub不同之处是GitLab flow又考虑多环境部署等现实因素，增加production产品分支用于在不同的环境下部署产品，或者从master的稳定版本创建release发布分支用于发布软件。
TBD flow
TBD (Trunk-based Development) flow是由Paul Hammant于2013年提出的模型, TBD flow最大的特点是所有开发都基于主干trunk，不再有长期的开发分支，要求所有的提交尽快回到主干，这样可以共享最新的代码，并且能尽可能地减少合并冲突。如果需要发布版本，可以基于trunk直接生成新的分支用于发布。
TBD++ flow
TBD++ flow是Arrus公司软件研发部门从2015年开始一直沿用的Git分支管理模型，产品项目的客户主要是电信级服务运营商，每个国家或地区的需求在主要功能上一致，但在客户定制化方面又存在不少差异，同时项目开发周期较长，整个周期一般在3个月到2年之间，软件产品在项目前期需要有快速的迭代，在项目后期需要有稳定的发布版本。TBD++ flow以敏捷开发为核心，同时吸收了以上几个主流模型的优点。
以上几个主流的git代码分支管理模型各具特点，流程只是一个辅助工具，没有最好，只有最合适，例如，如果开发团队规模较小又比较分散，产品发布周期较短，可以选择GitHub flow或者GitLab flow；如果开发团队规模较大，产品发布周期较长可以选择Git flow，发布周期较短可以选择TBD flow；如果开发团队规模大，产品发布周期长，同时对敏捷的要求比较高，可以考虑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 分支经过代码评审及功能测试后合并到 master 分支，测试人员再从 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。
