本文介绍一种使用Git进行源代码管理的分支模型，着重于如何使用Git更好的管理我们的源代码。
我假定您对Git有一定了解，会使用基本的Git命令进行一些简单的源代码管理工作。这不是一篇Git使用教程。
文章的主要思想源自以下链接：
http://nvie.com/posts/a-successful-git-branching-model/
根据自己的使用情况进行了补充。
我们知道Git是一个不需要中心服务器就能工作的源代码管理系统；但我仍然建议你至少保持一个逻辑上的中心服务器来存放你的长期分支（后文我们会说到什么是“长期分支”，什么是“临时分支”）。我说“逻辑上”的中心服务器，意思是你不必搭建一个真实的服务器——当你只是在实现一个小型应用时，可能开发人员只有你一个人，这个时候你完全可以将长期分支就放在你的项目目录里。
首先看一张图：
这张图上有这么几个分支：master，develop，feather，hotfix，release。它们之间存在着branch和merge的关系。我们从master和develop开始。
master和develop分支都是长期分支，它们存在于整个项目存续期内。
master分支是整个项目的主分支。
所有其他分支都直接或间接源自master。master分支是可直接用于产品发布的代码。
develop分支反映最新的开发进程。
develop中的代码总是可以完整build的。当develop中的代码进入稳定状态（修复了绝大多数bug）准备release时，所有develop中的更改将通过release branch最终merge到master。
除master和develop以外的分支都是临时分支。当这些临时分支完成其使命，就可以删除它们。我们先看feather分支。
feather分支用于某个新feather的开发，源自develop，并最终merge到develop。
feather分支最终的结局要么合并到develop branch，要么被抛弃。feather分支用如下命令创建：
# git checkout –b my feather develop
完成后将这个feather合并到develop：
# git checkout develop
# git merge --no-ff myfeather
# git branch –d myfeather
# git push origin develop
合并时--no-ff选项避免fast forward。使用该选项和不使用该选项得到的分支路线图分别如下：
release分支用于准备新版本的发布。源自develop，merge到develop和master。
release分支仅修复小的bug，完成准备版本号，build date等工作。而develop分支可以同时开始新feather的开发。该分支上修复的bug需要merge到develop，并在该分支完成时merge到master。此时需要给master打上tag，标记这个新的release。
创建release branch：
# git checkout –b release-x.y develop
完成release branch
# git checkout master
# git merge --no-ff release-x.y
# git tag –a x.y
# git checkout develop
# git merge --no-ff release-x.y
# git branch –d release-1.2
Hotfix分支用于紧急bug修复，源自master，merge到develop和master。
对于已发布的产品，可能有意外的紧急bug需要修复。hotfix branch可以避免修复bug的工作影响develop branch。
创建hotfix branch：
# git checkout -b hotfix-x.y master
完成hotfix branch：
# git checkout master
# git merge --no-ff hotfix-x.y
# git tag –a x.y.z
# git checkout develop
# git merge --no-ff hotfix-x.y
# git branch –d hotfix-x.y
这里有个例外就是，如果hotfix发生时有正在进行的release branch，那么将hotfix merge到release，而release最终会merge到develop和master。
到此我们的分支模型介绍就完毕了。我使用这个branch model有几个月了，感觉是：Great！