分享一些项目中使用的开发模型，它们的结果都非常成功，篇幅有限，这里仅讨论分支策略和发布管理。
为何使用 git？
关于 Git 和集中式源码版本控制系统的优缺点自己www.baidu.com,Git 真的改变了我关于合并和分支的认知，使用 Git，因为具有简单和可重复的基因，分支和合并不再是什么值得担心的问题了。版本控制工具应该专注于分支/合并，而非其他事情。
关于工具的了解已经够了，下面就开始进入开发模型了。这个我要介绍的开发模型，不过是每个团队成员进入软件开发流程之前必须遵循的规范。
去中心化和中心化
基于一个「真正」中心库的这种分支模型可以让我们很好的协同工作。注意这个库仅仅是被认为一个中心库（因为 GIT 在技术角度并没有中心库这一说法）。我们将此仓库命名为 origin!
所有开发者都从 origin 库拉取或向其推送代码。在中心化的推送-拉取关系之外，开发者也可以从其他的开发者库拉取代码更改。例如，为了开发一个大型功能，有多位开发者组成一个开发小组，在功能完成之前，开发过程不必推送至 origin 库。在上面的图中就有 Alice 和 Bob， Alice 和 David，还有 Clair 和 David 之间组成的小组。
技术层面，Alice 要在本地库加一个远程 Git 分支并命名为 bob，指向 Bob 的仓库。其他人也一样。
主分支
git 的核心在开发模式上受到了现有模式的极大启发，中心仓库在整个生命周期保持了两个主要的分支：
- master
- develop
每个 Git 用户都对在 origin 的 master 分支很熟悉。 跟 master 分支并行的是另一个称为 develop 的分支。
我们称 origin/develop 为主分支，这个分支源码的 HEAD 总是反映下一个版本的最新开发状况。有些人称这个分支为 "整合分支" 。所有的每日自动构建都是从这儿构建的。
当 develop 分支上的源代码达到一个稳定点并准备发布时， 所有的更改都应该以某种方式合并回 master 分支， 然后使用发行版本进行标注。 接下来将从细节上讨论这是如何完成的。
因此， 每次将变更合并回 master分支时， 这是一个 根据定义 的新产品发布。 我们趋向于对此非常严格，因此理论上来讲， 我们可以在每次提交到 master 分支时， 使用一个 Git 钩子脚本来自动完成构建和发行我们的软件到生产服务器。
辅助分支
在讨论完 master 分支和 develop 分支后，将要讨论的多样化的辅助分支，支持成员间并行开发， 轻松跟踪功能开发、生产版本发布、还能快速修复生产环境中产生的 Bug 。和主分支不同的是，辅助分支只有有限的生命周期，通常在完成使命后会被删除。
可能用到的辅助分支分类有：
- 功能分支
- 发布分支
- 修复 Bug 分支
每个分支都有特殊的用途。这些分支的来源分支和他们要合并回的分支都有严格的定义。
功能分支
功能分支可能源自于：develop 分支
功能分支必须合并回：develop 分支
功能分支命名惯例：任何名字都可以，但不能包含 master， develop， release-*， 或者 hotfix-* 。
功能分支（或称为特性分支）是被用来开发新功能的，这些新功能是要即将上线或更长时间后发布的。功能分支创建后开始开发时，之后将要合并的时间点是不知道的。功能分支的精髓是伴随开发过程一直存在，但是肯定会被合并回 develop （在下一个预期的发布版本中清晰的添加新功能 ) 或被丢弃 (万一实验不尽如人意）。
功能分支通常存在开发人员的仓库中，不会出现在 origin 仓库。
发布分支
该分支可能源自于：develop 分支
必须合并到：develop 和 master 分支
分支命名习惯：release-*
发布分支（Release branches） 支持新产品发布的准备。 它们允许在最后一刻追求细节。此外，它们允许小错误修复以及为发布准备元数据（版本号，构建日期等）。通过在发布分支上做的这些工作， develop 分支被清除以接收下一个大版本的功能特性。
从 develop 分支检出一个新发布分支的重要时刻就是当开发（基本上）反映了新版预期状态的时候。 至少，在那时，所有以『即将构建的发布版』（ release-to-be-built ）为目标的功能特性必须合并回 develop 分支。 针对未来版本的所有功能则可能不会 —— 它们必须等到发布分支检出以后才可以这么做。
热修复分支
分支可能来自于：master
必须合并到：develop 和 master
分支命名惯例：hotfix-*
热修复（hotfix）分支和发布（release）分支很像，因为它们都意味着即将有新的生产版本发布，尽管不是意料之中的。它们产生的原因是现有的生产版本出现了不受欢迎的情况，从而必须立即起作用。当生产版本中的一个严重的 bug 必须马上被修复，热修复分支可能从 master 分支上用于标记生产版本的对应标签上创建分支。
其本质是当有人准备对生产版本进行快速修复时，团队成员（在 develop 分支）可以继续工作。
总结：
虽然这种分支模式目前看来已经不是什么新鲜事了，但这篇文章开头的 「大图」已经证明，这种模式对项目实实在在的是非常有用。它形成了一个优雅并且更加容易理解的模型，并且能加强团队中成员们对于分支和其释放过程的理解。
PS:觉得有用的朋友可以收藏下哦，顺便点下关注。。。