译文：一个成功的 Git 分支模型 A successful Git branching model

Question

在本文中，我介绍了大约一年前我为一些项目（工作和私有）介绍的开发模型，结果证明非常成功。 我一直想写一段时间，但直到现在我才真正抽出时间做这件事。 我不会谈论任何项目的细节，只是关于分支策略和发布管理。

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 分支开始

为什么用 Git？

有关Git与集中式源代码控制系统相比优缺点的详细讨论，请参阅网站。那里有很多争论。

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 缺点
the pros and cons 利弊

作为开发人员，我更喜欢Git，而不是今天的所有其他工具。
Git真的改变了开发人员对合并和分支的看法。

As a developer, I prefer Git above all other tools around today.
Git really changed the way developers think of merging and branching.

从我来自经典的CVS / Subversion世界来看，合并/分支一直被认为有点可怕（“要小心合并冲突，它们会咬你！”）以及你每隔一段时间就会做的事情。

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，这些操作非常便宜和简单，并且它们被认为是您日常工作流程的核心部分之一。例如，在CVS / Subversion书籍中，分支和合并首先在后面的章节中讨论（对于高级用户），而在每本Git书中，它已经在第3章（基础知识）中介绍过了。

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).

由于其简单性和重复性，分支和合并不再是一件令人害怕的事情。版本控制工具应该比其他任何东西更有助于分支/合并。

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 简单
repetitive 重复
nature 性质

足够的工具，让我们进入开发模型。我将在这里介绍的模型基本上只是每个团队成员必须遵循的一组程序才能进入托管软件开发过程。

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.

分散但集中

我们使用的存储库设置与该分支模型配合良好，具有中央“真实”存储库。 请注意，这个仓库只被认为是中央仓库（因为Git是DVCS，在技术层面没有中央仓库）。 我们将此repo称为origin，因为所有Git用户都熟悉此名称。

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.

参考原文：https://nvie.com/posts/a-successful-git-branching-model/