介绍一个成功的 Git 分支模型

　　在这篇文章中，我提出一个开发模型。我已经将这个开发模型引入到我所有的项目里(无论在工作还是私人)已经一年有余，并且它被证明是非常成功的。我打算写这些已经很久了，但我一直找不到时间来做，现在终于有时间了。我不会讲任何项目的具体细节，仅是关于分支策略和释放管理相关内容。

　　它主要体现了Git对我们源代码版本的管理。

　　为何是Git?

　　对于Git与其他集中式代码管理工具相比的优缺点的全面讨论，请参见这里。这样的争论总是喋喋不休。作为一个开发者，与现今的其他开发工具相比较，我更喜欢Git。Git真得改变了开发者对于合并和分支的思考。我曾经使用经典的CVS/Subversion，然而每次的合并/分支和其他行为总让人担惊受怕(“小心合并里的冲突，简直要命!”)。

　　但是对于Git来说，这些行为非常简单和搞笑，它们被认为是日常工作中的核心部分。例如，在很多CVS/Subversion书里，分支与合并总是在后面的章节中被讨论(对于高级用户使用)，然而在每个Git书中，在第3章就已经完全涵盖了(作为基础)。

　　简单和重复的特性带来的结果是：分支与合并不再是什么可以害怕的东西。分支/合并被认为对于版本管理工具比其他功能更重要。

　　关于工具，不再多说，让我们直接看开发模型吧。这个模型并不是如下模型：在管理软件开发进度方面，面对每个开发过程，每个队员必须按一定次序开发。

　　分布式而非集中式

　　对于这种分支模型，我们设置了一个版本库，它运转良好，这是一个”事实上” 版本库。不过请注意，这个版本库只是被认为是中心版本库(因为Git是一个分布式版本管理系统，从技术上来讲，并没有一个中心版本库)。我们将把这个版本库称为原始库，这个名字对所有的Git用户来说都很容易理解。

　　每个开发者都对origin库拉代码和提交代码。但是除了集中式的存取代码关系，每个开发者也可以从子团队的其他队友那里获得代码版本变更。例如，对于2个或多个开发者一起完成的大版本变更，为了防止过早地向origin库提交工作内容，这种机制就变得非常有用。在上述途中，有如下子团队：Alice和Bob，Alice和David，Clair和David。

　　从技术上将，这意味着，Alice创建了一个Git的远程节点，而对于Bob，该节点指向了Bob的版本库，反之亦然。

　　主分支

　　在核心部分，研发模型很大程度上靠其他现有模型支撑的。中心库有2个可一直延续的分支：

　　master分支

　　develop分支

　　每个Git用户都要熟悉原始的master分支。与master分支并行的另一个分支，我们称之为develop分支。

　　我们把原始库/master库认作为主分支，HEAD的源代码存在于此版本中，并且随时都是一个预备生产状态。

　　辅助性分支

　　我们的开发模型使用了各种辅助性分支，这些分支与关键分支(master和develop)一起，用来支持团队成员们并行开发，使得易于追踪功能，协助生产发布环境准备，以及快速修复实时在线问题。与关键分支不同，这些分支总是有一个有限的生命期，因为他们最终会被移除。

　　我们用到的分支类型包括：

　　功能分支

　　发布分支

　　热修复分支

　　每一种分支有一个特定目的，并且受限于严格到规则，比如：可以用哪些分支作为源分支，哪些分支能作为合并目标。我们马上将进行演练。

　　从技术角度来看，这些分支绝不是特殊分支。分支的类型基于我们使用的方法来进行分类。它们理所当然是普通的Git分支。

　　功能分支

　　可能是develop分支的分支版本，最终必须合并到develop分支中。

　　分支命名规则：除了master、develop、release-*、orhotfix-*之外，其他命名均可。

　　功能分支(有时被称为topic分支)通常为即将发布或者未来发布版开发新的功能。当新功能开始研发，包含该功能的发布版本在这个还是无法确定发布时间的。功能版本的实质是只要这个功能处于开发状态它就会存在，但是最终会或合并到develop分支(确定将新功能添加到不久的发布版中)或取消(譬如一次令人失望的测试)。

　　功能分支通常存在于开发者的软件库，而不是在源代码库中。

　　创建一个功能分支

　　开始一项功能的开发工作时，基于develop创建分支。

　　合并一个功能到develop分支

　　完成的功能可以合并进develop分支，以明确加入到未来的发布：

原文转自：http://blog.jobbole.com/34706/