原文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来自动构建和转出到产品服务器上。辅助分支