Git代码分支管理模型

简介

现代软件开发过程中要实现高效的团队协作，需要使用代码分支管理工具实现代码的共享、追溯、回滚及维护等功能。目前流行的代码管理工具，包括CVS，SVN，Git，Mercurial等。相比CVS和SVN的集中管理，Git具有非常明显的优势，例如：去中心化的代码管理方式减少了开发者对中心服务器的依赖，每个成员在本地都有一个完整的代码库，在不联网的情况下也能提交代码；不同于SVN中的每个分支具有独立的代码，Git中的每一个分支只是指向当前版本的一个指针，Git的分支策略使创建和合并分支变得快捷灵活。

根据开源社区网站OpenHub的统计，使用Git管理代码的项目逐年快速增加，如今Git在代码管理领域已经占据主导地位。​​

在使用Git管理代码以及多人协作的开发模式下，一个团队甚至一个公司对Git的使用有统一规范的工作流程尤为重要，开发团队遵循统一的规则执行功能开发，问题修复，分支合并，版本迭代及发布等操作，可以使团队合作变得平滑顺畅，项目有序向前推进，我们把组织内这样的工作流程（workflow）称为Git代码分支管理模型，本文将介绍几个主流的git代码分支管理模型：

• Git flow
• GitHub flow
• GitLab flow
• TBD flow

Git flow

Git flow是由Vincent Driessen于2010 年提出的代码分支管理模型，但是不要被名字欺骗了，git-flow并不是Git社区官方推荐的工作流。

Git flow存在两个长期的独立分支：主分支master和开发分支develop，主分支用于版本发布，主分支的每个版本都是质量稳定和功能齐全的发布版。开发分支用于日常开发工作，存放最新的开发版代码。当开发分支的代码达到稳定状态并可以发布版本时，代码需要被合并到 master 分支，然后标记上对应的版本标签（tag）。

如果需要开发新的功能或者解决代码中的问题，则创建辅助分支来解决问题，辅助分支常用于：功能开发（Feature），版本发布（Release），问题修复（Hotfix）等，在辅助分支上的工作完成后，辅助分支将被删除。

• Feature分支的目的是开发新模块或新功能以满足客户需求，从develop分支创建，开发结束后只需要合并回develop分支，并不需要合并回master主分支。

• Release分支是用于准备发布的版本分支，从develop分支创建，创建时已经包含了发布所需要的所有功能，所以在这个分支上不再开发新功能，仅对这个预发布版本进行修复问题，创建文档及其他与发布相关的工作，一切就绪后将Release分支合并回master主分支并打上相应的版本号标签（Tag），同时也合并回develop分支。创建单独的Release分支可以避免在