git 管理模型
分布式但集中化，这是对 git 管理模型最好的阐述。模型图如下图所示：
上图中 origin 是一个 ” 中心库 ” ，当然这个中心库只是被认为是这样 ( 因为 Git 是分布式的，从技术层面上来说是没有中心库的 ) 。
每个开发者 pull 和 push 到 origin ，但除了中心化的 push-pull 关系外，每个开发者还可以从其他开发者那 pull changes 。比如说，对于一个比较大的新特性，在把代码提交到 origin 之前，很可能会安排 2 个或多个开发者。上图中有几个小团队： Alice 和Bob ， Alice 和 David ， Clair 和 David 。团队成员先把代码 pull 到队长那里，再由队长 pull 到 origin 库。
主要分支设计
中心仓库有两个分支： master 和 develop 。
origin 上的 master 分支， Git 用户应该很熟悉，跟 master 并行的有一个 develop 分支
我们把 origin/master 作为主要分支，源码的 HEAD 总是表示 production-ready( 可随时部署 ) 状态。而 origin/develop 上的代码是为下一次的代码发布准备的。每日构建也是基于此分支。
当 develop 分支达到了一个稳定状态并准备发布时，所有的改变都要合并到 master 分支，并标上版本号。这样每次与 master 合并都会会有新的部署发布。如下是相关命令：
$git checkout –b develop master
在 develop 分支上进行开发工作。
$git checkout master
$git merge –no-ff develop
支持分支设计
我们的开发模型使用了一些支持分支放在 master 和 develop 分支的旁边，方便开发小组之间的并行开发。不像主要分支，这些分支是有时间限制的，因为他们最终都会被移除。
我们会使用到的不同的分支有： Feature branches 、 Release branches 、 Hotfix branches 。
每个分支都有各自的作用，并且有严格的规定，如：只能从哪个分支上去新开分支，只能合并到那个分支。
Feature branches
规定如下：
继承分支
: develop
合并分支：
develop
命名规范：除了 master,develop,release- ,hotfix-
Feature branches 是用来开发新特性的 ( 短期，远期都可以 ) 。当开始开发新特性时，很可能不知道这个特性会出现在哪个目标版本。一旦开发完成就可以合并到 develop，当然如果开发失败，就可以抛弃。
创建及完成一个 Feature branch
根据 Feature branches 的规定，创建命令如下：
$ git checkout -b myfeature develop
新特性完成时，可以合并到 develop
$ git checkout develop
$ git merge –no-ff myfeature
$ git branch -d myfeature
$ git push origin develop
—no-ff ( 注： no fast foward) 标签，使得每一次的合并都创建一个新的 commit 记录。即使这个 commit 只是 fast-foward ，这样可以避免丢失信息
