原文
A successful Git branching model
In this post I present the development model that I’ve introduced for all of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management.
这篇文章，将介绍所有一年前我工作中或者个人项目的开发模型，这个模型已经被证明是十分有用的（successfull）。我老早就想写一些关于这个模型的文章，但是总是抽不出时间。在这篇文章中，我将不会介绍项目的详细情况，仅仅对分支的策略和发布管理作一个介绍。
It focuses around
Git as the tool for the versioning of all of our source code.
我们将围绕这使用
Git作为所有项目源码的版本控制工具。
For a thorough discussion on the pros and cons of Git compared to centralized source code control systems,
see the web. There are plenty of flame wars going on there. As a developer, I prefer Git above all other tools around today. Git really changed the way developers think of merging and branching. From the classic CVS/Subversion world I came from, merging/branching has always been considered a bit scary (“beware of merge conflicts, they bite you!”) and something you only do every once in a while.
关于Git作为集中的源码控制系统的优缺点，可以查看一下
链接，关于这个话题，有激烈的争论。作为一个开发者，与其他版本控制工具相比，我更喜欢Git，Git真正的改变了开发者关于合并和分支的思考（think）。我曾经也用过CVS、svn，分支和合并，真的很让人头疼（合并时产生的冲突），因此，有时你每次只能做一会工作（个人理解：因为svn这种版本控制库只有一个服务仓库，涉及公共资源，只能锁定编辑）
But with Git, these actions are extremely cheap and simple, and they are considered one of the core parts of your
daily workflow, really. For example, in CVS/Subversion
books, branching and merging is first discussed in the later chapters (for advanced users), while in
every Git book, it’s already covered in chapter 3 (basics).
但是对于Git来说，做这样的工作（分支、合并），太简单！它真的可以作为你日常工作流程中最核心的部分。例如，在有关CVS/svn的
书籍中，分支和合并要放到最后一章才会阐述（针对高级用户），然后在Git相关的
书籍中，首先就先跟你阐述分支和合并（第3章）。
Enough about the tools, let’s head onto the development model. The model that I’m going to present here is essentially no more than a set of procedures that every team member has to follow in order to come to a managed software development process.
关于这个工具的介绍，我们不再赘述，现在我们回到开发模式的话题上来。这个模型，基本上和每个开发团队管理软件开发流程是类似的。
The repository setup that we use and that works well with this branching model, is that with a central “truth” repo. Note that this repo is only considered to be the central one (since Git is a DVCS, there is no such thing as a central repo at a technical level). We will refer to this repo as origin, since this name is familiar to all Git users.
我们使用这个分支模型很好工作的仓库，是真正意义上的中央仓库。这个仓库是唯一的中央仓库（因为Git本身就是分布式版本控制系统DVCS，所以这没有技术问题）。我们称这样一个中央仓库为origin，所有Git用户都知道origin这个名称。
Each developer pulls and pushes to origin. But besides the centralized push-pull relationships, each developer may also pull changes from other peers to form sub teams. For example, this might be useful to work together with two or more developers on a big new feature, before pushing the work in progress to origin prematurely. In the figure above, there are subteams of Alice and Bob, Alice and David, and Clair and David.
每个开发者，都可以从origin获得（pull）资源，同时也能推送（push）到origin。除此之外，每个开发者可以从其他开发者那里获得资源，以此组建自己的一个小组。例如，当我们要开发一个大的新功能时，我们将和其他人一起协作，在提交到中央仓库origin之前，我们需要小组内部能够互相协作，这将是十分有用的。上图中，Alice和Bob是一个小组，同时Alice和David是一个小组，Clair和David又是一个小组。
Technically, this means nothing more than that Alice has defined a Git remote, named bob, pointing to Bob’s repository, and vice versa.
从技术实现上讲，这无非是在Alice的项目里，定义了一个指向Bot的远程链接而已（git remote add bob git@bobserver bob.git)，反之也是一样，如此简单！！
At the core, the development model is greatly inspired by existing models out there. The central repo holds two main branches with an infinite lifetime:
中央仓库有2个主要的分支，这些分支将一直存在：
The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists called develop.
中央仓库的master分支已经为所有Git用户熟知，与master分支并行的另外一个分支，我们称之为develop。
We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
我们称origin/master为主要分支，因为分支的HEAD指向的源码总是反映了一个可以发布的产品状态（production-ready）。
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.
我们称origin/develop为主要分支，因为分支的HEAD指向的源码，总是反映了下次发布前最新提交的开发代码。有些人称之为“集成分支”（integration barnch），因为我们的每晚自动构建都是基于此分支进行的。（例如hudson，可以做自动构建工作）。
When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number. How this is done in detail will be discussed further on.
当develop分支的源码稳定并且准备发布，所有的改变应该合并（merge）到master分支，同时做一个发布版本的标签（tag），我们将在后面讨论这个细节。
Therefore, each time when changes are merged back into master, this is a new production release by definition. We tend to be very strict at this, so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master.
因此，当每一次将所有更改合并回master时，将会产生一个新的可以发布的产品状态。我们往往对于这个操作的控制是比较严格的，每当往master分支提交时，我们可以使用Git的hook来自动构建和转出到产品服务器上。