【译】有用的git分支模型

原文A successful Git branching modelIn 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作为所有项目源码的版本控制工具。为何选择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个主要的分支，这些分支将一直存在： master develop 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来自动构建和转出到产品服务器上。辅助分支