一個(gè)成功的Git分支模型
A successful Git branching model
[參考原文]https://nvie.com/posts/a-successful-git-branching-model/
作者： Vincent Driessen
image.png
on Tuesday, January 05, 2010
在本文中，我介紹了大約一年前我為一些項(xiàng)目（工作和私有）介紹的開(kāi)發(fā)模型，結(jié)果證明非常成功。 我一直想寫(xiě)一段時(shí)間，但直到現(xiàn)在我才真正抽出時(shí)間做這件事。 我不會(huì)談?wù)撊魏雾?xiàng)目的細(xì)節(jié)，只是關(guān)于分支策略和發(fā)布管理。
In this post I present the development model that I’ve introduced for some 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.
看圖由master分支開(kāi)始
為什么用Git？
有關(guān)Git與集中式源代碼控制系統(tǒng)相比優(yōu)缺點(diǎn)的詳細(xì)討論，請(qǐng)參閱網(wǎng)站。那里有很多爭(zhēng)論。
Why 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.
pros 利弊
cons 缺點(diǎn)
the pros and cons 利弊
作為開(kāi)發(fā)人員，我更喜歡Git，而不是今天的所有其他工具。
Git真的改變了開(kāi)發(fā)人員對(duì)合并和分支的看法。
As a developer, I prefer Git above all other tools around today.
Git really changed the way developers think of merging and branching.
從我來(lái)自經(jīng)典的CVS / Subversion世界來(lái)看，合并/分支一直被認(rèn)為有點(diǎn)可怕（“要小心合并沖突，它們會(huì)咬你！”）以及你每隔一段時(shí)間就會(huì)做的事情。
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，這些操作非常便宜和簡(jiǎn)單，并且它們被認(rèn)為是您日常工作流程的核心部分之一。例如，在CVS / Subversion書(shū)籍中，分支和合并首先在后面的章節(jié)中討論（對(duì)于高級(jí)用戶(hù)），而在每本Git書(shū)中，它已經(jīng)在第3章（基礎(chǔ)知識(shí)）中介紹過(guò)了。
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).
由于其簡(jiǎn)單性和重復(fù)性，分支和合并不再是一件令人害怕的事情。版本控制工具應(yīng)該比其他任何東西更有助于分支/合并。
As a consequence of its simplicity and repetitive nature, branching and merging are no longer something to be afraid of. Version control tools are supposed to assist in branching/merging more than anything else.
consequence 后果
simplicity 簡(jiǎn)單
repetitive 重復(fù)
nature 性質(zhì)
足夠的工具，讓我們進(jìn)入開(kāi)發(fā)模型。我將在這里介紹的模型基本上只是每個(gè)團(tuán)隊(duì)成員必須遵循的一組程序才能進(jìn)入托管軟件開(kāi)發(fā)過(guò)程。
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.
分散但集中
我們使用的存儲(chǔ)庫(kù)設(shè)置與該分支模型配合良好，具有中央“真實(shí)”存儲(chǔ)庫(kù)。 請(qǐng)注意，這個(gè)倉(cāng)庫(kù)只被認(rèn)為是中央倉(cāng)庫(kù)（因?yàn)镚it是DVCS，在技術(shù)層面沒(méi)有中央倉(cāng)庫(kù)）。 我們將此repo稱(chēng)為origin，因?yàn)樗蠫it用戶(hù)都熟悉此名稱(chēng)。
Decentralized but centralized
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.
