良好的分支管理有利于整个项目的稳步迭代与团队成员间的密切合作，故而本文将介绍一个成熟的git分支管理模型，用作实践参考。

最终效果图

主分支

master和develop主分支

中心仓库持有两条生命期为无限的分支：
1.主分支（master）
2.开发分支（develop）

master 分支

我们将 origin/master 作为一条主分支，其头指针 HEAD 总是指向一个生产就绪的状态。所以，每一次有修改部分被合并到 master 分支时，就意味着一个新的产品已经被发行出来，即我们的git脚本将会自动构建或回滚我们的软件，并将其部署到生产服务器中。

develop 分支

我们把 origin/develop 作为另一条主分支，其头指针 HEAD 总是指向最新一次提交的开发更新版本，该更新版本用于下一个版本的发行。这也就是说，当 develop 分支上的代码达到了一个相对稳定的、能发行的时候，所有在 develop 分支上的代码都应该被合并到 master 分支上去，并用一个新的发行号来标记它。

支承分支

在主分支下，本模型使用了三种不同的支承分支来帮助解决团队成员之间的平行开发、发行准备及现场部署所带来的问题。不同于主分支，这些支承分支的生命周期是有限的，最终肯定会被移除。

支承分支包括：
1.特征分支（Feature branches）
2.发行分支（Release branches）
3.热补丁分支（Hotfix branches）

Feature 分支

Feature 分支

Feature 分支从 develop 分支分离出来，最终会合并到 develop 分支中去。

有时，我们开发新功能的时候，并不知道该新功能将会在未来的哪个版本发行，甚至会被丢弃。这时就可以使用 Feature 分支，当该新功能开发完成时，Feature 分支会被合并到 develop 分支，或者直接被丢弃。

Release 分支

Release 分支从 develop 分支分离出来，最终会合并到 master/develop 分支中去。

Release 分支用于为新产品的发行作准备，如漏洞修补，准备元数据等。若当前版本为1.1.5的产品有一个大的版本1.2（而不是1.1.6或者2.0）即将推出，，那么我们就会从 develop 分支分离一条 Release 分支，当该 Release 分支到达能真正发行的状态时，就可以将其合并到 master 分支上，同时，为保证以后的发行不会遗漏这些小漏洞的修复，还需将其合并回 develop 分支。

注意，严格禁止在 release 分支上添加新的大功能。

Hotfix 分支

Hotfix 分支

Hotfix 分支从 master 分支分离出来，最终会合并到 master/develop 分支中去。

若当前产品有一个漏洞必须得就快修复，那么我们可以从 master 分支上分离出一条 hotfix 分支，如此一来，当团队中有一个成员去修复产品漏洞时，其他工作于 develop 分支的团队成员就可以继续工作，而不相互产生影响了。

特别的，当同时有一个 release 分支存在时，因为release 分支最终也会合并到 develop 分支，所以 hotfix 分支应该合并到该 release分支，而不是 develop 分支。