原文
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來自動構建和轉出到產品服務器上。