版本控制7 (译文)-(连载)

译:只是路过
 

Chapter 7: Branches

第7章：分支

This is part of an online book called Source Control HOWTO, a best practices guide on source control, version control, and configuration management.

这是一篇名为如何做源码控制的在线书籍的一部分，一本关于源码控制、版本控制、配置管理的最佳实践手册。

---

What is a branch?

什么是分支？

A branch is what happens when your development team needs to work on two distinct copies of a project at the same time.  This is best explained by citing a common example:

分支就是当你的开发团队需要同一时间工作的一个项目完全不同的两个拷贝。通过一个普通的例子就可以做一个最好的解释：

Suppose your development team has just finished and released version 1.0 of UltraHello, your new flagship product, developed with the hope of capturing a share of the rapidly growing market for "Hello World" applications. 

假设你的开发团队刚好完成和发布了产品的1.0版本，UltraHello是你的新旗舰产品，希望开发来用于获取一个对快速增长的“Hello World”应用程序的市场占领。

But now that 1.0 is out the door, you have a new problem you have never faced before.  For the last two years, everybody on your team has been 100% focused on this release.  Everybody has been working in the same tree of source code.  You have had only one "line of development", but now you have two:

 

但是现在1.0已经发布出去了，你遇到一个之前没有面临过的问题。过去的两年，你的所有团队人员都100%的专注于这次发布。每个人都在同一棵源码树上工作。你过去只有一条“开发线”，但是你现在有两条了：

 

_        Development of 2.0.  You have all kinds of new features which just didn't make it into 1.0, including "multilingual Hello", DirectX support for animated Hellos, and of course, the ability to read email. 

_        Maintenance of 1.0.  Now that real customers are using UltraHello, they will probably find at least one bug your testing didn't catch.  For bug fixes or other minor improvements requested by customers, it is quite possible that you will need to release a version 1.0.1.

 

_        2.0产品的开发。做你所有1.0里面没有包含的新特性，包括支持生动的打招呼所要用到的“多语言的Hello”，DirectX支持灵活的说Hello，当然，还可以读邮件。

_        1.0的维护。现在真正的用户在使用UltraHello，他们会找出至少一个你测试的时候没有发现的错误。出于对客户的其他小的改进意见、错误修复的考虑，你非常有必要发布一个1.0.1版本。

 

It is important for these two lines of development to remain distinct.  If you release a version 1.0.1, you don't want it to contain a half-completed implementation of a 2.0 feature.  So what you need here is two distinct source trees so your team can work on both lines of development without interfering with each other.

 

保持两条截然不同的开发线是非常重要的。如果你发布了一个1.0.1的版本，你不打算包含2.0的哪怕一半的特性。那就需要两个不同的源码树，你的团队可以在不干扰对方的情况下工作。

 

The most obvious way to solve this problem would simply be to make a copy of your entire source control repository.  Then you can use one repository for 1.0 maintenance and the other repository for 2.0 development.  I know people who do it this way, but it's definitely not a perfect solution.

 

最显而易见的解决这个问题的方法就是做一整个源码库的拷贝。你可以使用一个库来做1.0的维护，然后另一个库做2.0的开发。我知道有人这样干，但是很显然这不是一个完美的方案。

 

The two-repository approach becomes disappointing in situations where you want to apply a change to both trees.  For example, every time we fix a bug in the 1.0 maintenance tree, we probably also want to apply that same bug fix to the 2.0 development tree.  Do we really want to have to do this manually?  If the bug fix is a simple change, like fixing the incorrect spelling of the word "Hello", then it won't take a programmer very long to make the change twice.  But some bug fixes are more involved, requiring changes to multiple files.  It would be nice if our source control tool would help.  A primary goal for any source control tool should be to help software teams be more concurrent, everybody busy, all at the same time, without getting in each other's way.

 

两个库的方式会在你打算将一个变更应用到所有树的时候变得令人失望。例如，每次我们在1.0维护树上修正一个错误，可能想要应用这个错误的修复到2.0的树上。那我们真的愿意手工来做这个事情？如果错误修复是一个简单的变化，比如改正单词“Hello”的拼写错误，修改两次不会花开发人员很长的时间去。但是有的错误修复是很棘手的，需要变更好多个文件。那最好就是配置管理工具可以帮忙了。任何配置管理工具一个主要的目的就是应该可以帮助开发团队更有效的协作，每个人都忙，在同一时间，可以不用打扰别人的工作。

 

To address this very type of problem, source control tools support a feature which is usually called "branching".  This terminology arises from the tendency of computer scientists to use the language of a physical tree every time hierarchy is involved.  In this particular situation, the metaphor breaks down very quickly, but we keep the name anyhow.

 

为了诠释这个典型的问题，配置管理工具支持一个常用的称为“分支”的特性。这个术语起因于计算机科学趋向于每次涉及层级的时候使用一棵物理树表达。在这种特殊情况下，隐含意思已经迅速的消失了，但是这个名字还是保留了下来。

 

A somewhat better metaphor happens when we envision a nature path which forks into two directions.  Before the fork, there was one path.  Now there are two, but they share a common history.  When you use the branching feature of your source control tool, it creates a fork in the path of your development progress.  You now have two trees, but the source control has not forgotten the fact that these two trees used to be one.  For this reason, the SCM tool can help make it easier to take code changes from one fork and apply those changes to the other.  We call this operation "merging branches", a term which highlights why the physical tree metaphor fails.  The two forks of a nature path can merge back into one, but two branches of an oak tree just don't do that.  I'll talk a lot more about merging branches in the next chapter.

 

一个稍微好点的比喻在我们假想一个自然的路线发生，就是那种两个方向的分叉。开始分叉前，他们是一个路线。现在是两个，但是他们共享一个共同的历史。当你使用你的配置管理工具的分支特性的时候，它在你的开发过程当中的路线上面创建了一个分叉。你现在就有两棵树了，但是配置工具不会忘记有两棵树但通常只用一个的事实。基于这个原因，配置管理工具可以帮助我们在一个分支进行代码变更并应用那些变更到另一个分支上变得简单些。我们称这个操作为“合并分支”，这是一个精辟的术语，隐含了物理树失败的原因。一个自然路线的两个分叉可以合并到一个里面，但是一棵橡皮树的两个分支是不可以那样的。我会在下一章更多的讲到合并分支。

 

At this point I should take a step back and admit that my example of doing 1.0 maintenance and 2.0 features is very simplistic.  Real life examples are sometimes far more complicated, involving multiple branches, active development in each branch, and the need to easily migrate changes between any two of them.  Branching and merging is perhaps the most complex operation offered by a source control tool, and there is much to say about it.  I'll begin with some "cars and clocks" stuff and talk about how branching works "under the hood".

 

在这一点，我要回退一步，然后承认我关于做1.0的维护和2.0的特性的例子是非常简单的。真实生活的例子是有时要复杂得多，包含多重分支，每个分支都在开发，并且需要容易的在任意两棵树间移植变化。分支和合并可能是配置管理工具提供的最复杂的操作，这里有太多要说的了。我将从“车和钟”那个故事开始谈论分支是怎样“在引擎盖下”工作的。

 

Two branching models

两个分支模式

 

Best Practice: Organize your branches

最佳实践：组织你的分支
The "folder" model of branching usually requires you to have one extra level of hierarchy in your repository tree. Keep your main development in a folder named $/trunk. Then create another folder called $/branches. Each time you create a branch off of the trunk, put it in $/branches.

分支的“目录”模式通常需要你在你的库树中有一个额外的层级。在一个目录名为$/trunk的目录中保持你的开发。然后创建另一个叫做$/branches的目录。每次你从主干创建一个分支，就把它放到$/branches。

First of all, let's acknowledge that there are [at least] two popular models for branching.  In the first approach, a branch is like a parallel universe.

首先，我们要承认至少有两种分支流行的模式。第一个方式，一个分支就像一个并行的世界。

_        The hierarchy of files and folders in the repository is sort of like the regular universe. 

_        For each branch, there is another universe which contains the same hierarchy of files and folders, but with different contents.  

_        库中文件和目录的层级有点像规则的世界。

_        对应每个分支，都有另一个世界，包含了同样的文件和目录的层级，但是有不同的内容。

 

In order to retrieve a file, you specify not just a path but the name of the universe, er, branch, from which you want the file retrieved.  If you don't specify a branch, then the file will be retrieved from the "default branch".  This is the approach used by CVS and PVCS.

 

为了取得一个文件，你要指定文件在这个世界中的名字而不是路径，然后分支，从你希望取得文件的地方。如果你不指定分支，那这个文件将要从“缺省分支”获取。这是CVS和PVCS常用的方式。

 

In the other branching model, a branch is just another folder, located in the same repository hierarchy as everything else.  When you create a branch of a folder, it shows up as another folder.  With this approach, a repository path is sufficient to describe a location.

 

另一种分支模式里面，一个分支就是另一个目录，在同一个库中的另一个地方。当你创建一个目录的一个分支，它就以另一个目录显示。这种方式下，库路径就可以充分的表述位置了。

 

Personally, I prefer the "folder" style of branching over the "parallel universe" style of branching, so my writing will generally come from this perspective.  This is the approach used by most modern source control tools, including Vault, Subversion (they call it "copy"), Perforce (they call it "Inter-File Branching") and Visual Studio Team System (looks like they call it branching in "path space").

私下里，我喜欢“目录”风格的分支比“并行世界”风格的分支多些，所以我的描述将更多的基于这个观点。这个是现代的配置管理工具用到的方式，包括Vault，Subversion（在它里面被分支称为“复制”），Perforce（在它里面分支被称为“Inter－File Branching”），Visual Studio的Team System（好像他们称分支为“路径空间”）。

Under the hood

引擎盖下

Good source control tools are clever about how they manage the underlying storage issues of branching.  For example, let us suppose that the source code tree for UltraHello is stored in $/projects/Hello/trunk.  This folder contains everything necessary to do a complete build of the shipping product, so there are quite a few subfolders and several hundred files in there.

好的配置管理工具对于如何管理分支的潜在存储问题是聪明的。例如，假设UltraHello的代码树存放在$/projects/Hello/trunk中。这个目录包含了完成这个旗舰产品的构建所必须的所有东西，所以里面有相当多的子目录和好几百的文件在里面。

Now that you need to go forward with 1.0 maintenance and 2.0 development simultaneously, it is time to create a branch.  So you create a folder called $/projects/Hello/branches.  Inside there, you create a branch called 1.0.

现在你需要同时地在1.0维护和2.0开发上继续前行，是时候建立一个分支了。所以你创建了一个称为$/projects/Hello/branches的分支。在这里面，你创建一个叫1.0的分支。

At the moment right after the branch, the following two folders are exactly the same:

$/projects/Hello/trunk

$/projects/Hello/branches/1.0

在分支之后的那刻，下面两个目录会是完全的一样：

$/projects/Hello/trunk

$/projects/Hello/branches/1.0

It appears that the source control tool has made an exact copy of everything in your source tree, but actually it hasn't.  The repository database on disk has barely increased in size.  Instead of duplicating the contents of every file, it has merely pointed the branch at the same contents as the trunk.

看来好像是配置管理工具在你的源码树里面做了一个精确的拷贝，但是实际上不是。库只是在磁盘空间上增加了点。取代了为每个文件复制内容，它只是在为分支指定了像主干一样的内容。

As you make changes in one or both of these folders, they diverge, but they continue to share a common history.

当你在一个或者所有这些目录里面进行变更的时候，他们是分叉的，但是共享了一个共同的历史。

The Pitiful Lives of Nelly and Eddie

Nelly 和Eddie令人同情的生活

In order to use your source control tool most effectively, you need to develop just the right amount of fear of branching.  This delicate balance seems to be very difficult to find.  Most people either have too much fear or not enough.

为了使你的源码控制工具更为有效，你需要适度的平衡对分支的恐惧。这种微妙的平衡看来非常难以找到。很多人都有太多的担忧或者是担忧不够。

Nelly is an example of a person who has too much fear of branching.  Nelly has a friend who has a cousin with a neighbor who knows somebody whose life completely fell apart after they tried using the branch and merge features of their source control tool.  So Nelly refuses to use branching at all.  In fact, she wrote a 45-page policy document which requires her development team to never use branching, because after all, "it's not safe". 

Nelly就是一个对分支有过多恐惧的人的例子。Nelly有一个朋友，这个朋友的堂兄有个邻居，在他们疲于使用他们的源码控制工具的分支和合并特性，感到生命彻底绝望。所以Nelly也拒绝使用分支。实际上，她写一个45页的要求她的开发团队不要使用分支的文档，就因为“它不安全”。

So Nelly's development team goes to great lengths to avoid using branching, but eventually they reach a point where they need to do concurrent development.  When this happens, they do anything they can to solve the problem, as long as it doesn't involve the word "branch".  They fork a copy of their tree and begin working with two completely separate repositories.  When they need to make a change to both repositories, they simply make the change by hand, twice.

所以，Nelly的开发团队竭尽全力的去避免使用分支，但是在他们需要并行开发的时候他们就到达了一个点。当这一切发生的时候，他们做了他们能够为解决这个问题做的任何事情，只要不提到“分支”这个词。他们复制了他们的树的一个拷贝出来，然后开始在两个完全分离的库里面工作。当他们需要对两个库都进行一个变更的时候，他们就简单的手工进行两次变更。

Best Practice: Don't be afraid of branches
最佳实践：不要害怕分支
If you're doing parallel development, let your source control tool help. That's what it was designed to do.

如果你在做并行开发，那么让你的源码控制工具帮助你。那是它被设计出来的意义。

Obviously these people are still branching, but they keep Nelly happy by never using "the b word".  These folks are happy, and we should probably just leave them alone, but the whole situation is kind of sad.  Their source control tool has features which were specifically designed to make their lives easier.

显然，这些人们仍然在分支，但是他们通过不使用“这个字眼”来使Nelly高兴。人们是快乐的，我们应该只是让他们这样继续，但是整个情况是有点忧伤的。他们的源码控制工具应该有专为了使他们生活得更简单而设计的特性。

At the other end of the spectrum is Eddie, who uses branching far too often.  Eddie started out just like Nelly, afraid of branching because he didn't understand it.  But to his credit, Eddie overcame his fear and learned how powerful branching and merging can be.

在另一个极端的是Eddie，使用太频繁的分支。Eddie开始有点象Nelly，害怕使用分支，因为他不了解分支。但是值得表扬的是，Eddie克服了他的恐惧并且学会了如何有效的分支和必要的时候合并。

And then he went off the deep end.

但是他到了另一个极端。

After he tried branching and had a good first experience with it, Eddie now uses it all the time.  He sometimes branches multiple times per week.  Every time he makes a code change, he creates a private branch. 

当他试着分支并经历了一段最开始的使用分支的愉快体验之后，Eddie开始始终都使用分支了。他有时每周分支多次。每次他做一个代码变更就创建一个个人分支。

Eddie arrives on Monday morning and discovers that he has been assigned bug 7136 (In the Elbonian version, the main window is too narrow because the Elbonian language requires 9 words to say "Hello World".)  So Eddie sits down at his desk and begins the process of fixing this bug.  The first thing he does is create a branch called "bug_7136".  He makes his code change there in his "private branch" and checks it in.  Then, after verifying that everything is working okay, he uses the Merge Branches feature to migrate all changes from the trunk into his private branch, just to make sure his code change is compatible with the very latest stuff.  Then he runs his test suite again.  Then he notices that the repository has changed yet again, then he does this loop once more.  Finally, he uses Merge Branches to apply his code fixes to the trunk.  Then he grabs a copy of the trunk code, builds it and runs the test suite to verify that he didn't accidentally break anything.  When at last he is satisfied that his code change is proper, he marks bug 7136 as complete.  By now it is Friday afternoon at 4:00pm , and there's no point in starting anything new at this point, so he just decides to go home.

Eddie星期一早上到的时候，发现被分配了7136号缺陷（在阿尔波尼亚版本中，主窗口太窄了，因为阿尔波尼亚语说“Hello World”需要9个词。）所以Eddie坐到座位上然后开始修复这个缺陷。他做的第一件事情就是创建了一个叫做“Bug_7136”的分支。他就在他的“私人分支”上进行变更然后签入。在确认所有的代码都正常工作之后，他使用合并分支的特性将所有主干上的变更移植到他的私人分支，只是为了确保他的代码变更是同最新的版本是一致的。他就要再运行他的测试集合。然后他发现库已经又变更了，然后他就又重做一遍上述操作。最后，他使用合并分支来应用他的修复的代码到主干上。然后他从主干取一个代码拷贝，构建并运行测试来检查他没有出错。最后他确定他的修改是正确的，他就标示缺陷7136被修复了。此时是周五下午4：00了，没有其他需要开始做的事情了，他就打算回家了。

Eddie never checks anything into the main trunk.  He only checks stuff into his private branch, and then merges changes into the trunk.  His care and attention to detail are admirable, but he's spending far more time using his source control tool than working on his code.

Eddie没有签入任何东西到主干。他只是签入到他自己的分支，然后合并变更到主干上。他的小心谨慎是令人钦佩的，但是他花了比写代码还多的时间来使用他的源码控制工具。

Let's not even think about what the kids would be like if Eddie and Nelly were to get married.

我们不要去考虑如果Eddie和Nelly已经结婚了，他们是否喜欢孩子们。

Dev--Test—Prod

开发－测试－产品化

Once you established the proper level of comfort with the branching features of your source control tool, the next question is how to use those features effectively.

如果你创建了正确的层级来适应你的源码控制工具的分支的特性，那么下面这个问题就是讲如何有效使用这些特性的。

One popular methodology for SCM is often called "code promotion".  The basic idea here is that your code moves through three stages, "dev" (stuff that is in active development), "test" (stuff that is being tested) and "prod" (stuff that is ready for production release):

对于配置管理的一个流行的方法论被称为“代码升级”。这个基本的意思是你的代码经历了3个台阶，“开发”（正在开发中的项目），“测试”（正在测试的项目）和“产品化”（准备进行产品发布的项目）。

• As code gets written by programmers, it is placed in the dev tree.  This tree is "basically unstable".  Programmers are only allowed to check code into dev.
• When the programmers decide they are done with the code, they "promote" it from dev to test.  Programmers are not allowed to check code directly into the test tree.  The only way to get code into test is to promote it.  By promoting code to test, the programmers are handing the code over to the QA team for testing.
• When the testers decide the code meets their standards, they promote it from test to prod.  Code can only be part of a release when it has been promoted to prod.
• 因为代码是开发人员编写的，它被放在开发树中。这棵树是“基本不稳定地”。开发人员只允许签入代码到里面。
• 当开发人员确定他们完成了编码，他们就从开发到测试“升级”代码。开发人员不允许直接在测试树去取代码。在测试树里面唯一的取得代码的方式就是升级它。通过升级代码到测试，开发人员就提交代码给质量保证团队用于测试。
• 当测试人员确定代码符合他们的标准，他们就从测试到产品化升级它。代码进入产品化阶段，它可能只是发布的一部分。

For a variety of reasons, I personally don't like working this way, but there's nothing wrong with it.  Lots of people use this code promotion model effectively, especially in larger companies where the roles of programmer and tester are very clearly separated. 

基于种种原因，我个人不喜欢这个工作方式，但是这却没有错。很多人有效的使用这种代码升级方式，特别是在开发人员和测试人员分工非常清楚的大公司。

I understand that PVCS has specific feature support for "promotion groups", although I've never used this product personally.  With other source control tools, the code promotion model can be easily implemented using three branches, one for dev, one for test, and one for prod.  The Merge Branches feature is used to promote code from one level to the next.

我知道PVCS有特殊的特性来支持“升级组”，尽管我没有亲自使用这个产品。其他的源码控制工具，代码升级模式可能被简单的使用树的分支实现，一个用于开发，一个用于测试，一个用于产品化。合并分支的特性是用来一个台阶到下个台阶升级代码的。

Eric's Preferred Branching Practice

Eric首选的分支实践

Best Practice: Keep a "basically unstable" trunk.
最佳实践：保持一个“基本不稳定”的主干
Do your active development in the trunk, the stability of which increases as you approach release. After you ship, create a maintenance branch and always keep it very stable.

在主干做你的主要开发，随发布进行增加稳定性。在你发布之后，创建一个维护分支，并且使它很稳定。

Here at SourceGear our main development tree is called the "trunk".  In our repository it is rooted at $/trunk and it contains all the source code and documentation for our entire product.

在SourceGear，我们主要的开发树被称为“主干”。在我们的库里面，它从$/trunk生根，它包含了所有的源码和我们整个产品的文档。

Most new code is checked into the trunk.  In general, our developers try to never "break the tree".  Anyone who checks in code which causes the trunk builds to fail will be the recipient of heaping helpings of trash talk and teasing until he gets it fixed.  The trunk should always build, and as much as possible, the resulting build should always work.

很多代码被签入到主干上。通常，我们的开发人员试图决不“中断树”。任何人签入引起构建失败的代码的话，在他修复完之前就会被受到很多无聊的教导和揶揄。主干始终都在构建，只要需要，构建结果应该都是可以工作的。

Nonetheless, the trunk is the place where active development of new features is happening.  The trunk could be described as "basically unstable", a philosophy of branching which is explained in Essential CVS, a fine book on CVS by O'Reilly.  In our situation, the stability of the trunk build fluctuates over the months during our development cycle.

虽然如此，主干是新特性一直产生的场所。主干会被表述为“基本不稳定”，在《Essential CVS》中有一个关于分支的达观的解释，这是一本O’Reilly出版的关于CVS的好书.在我们的实际中，主干构建的稳定性波及到数月，贯穿我们的开发周期。

During the early and middle parts of a development cycle, the trunk is often not very stable at all.  As we approach alpha, beta and final release, things settle down and the trunk gets more and more stable.  Not long before release, the trunk becomes almost sacred.  Every code change gets reviewed carefully to ensure that we don't regress backwards.

在开发周期的早期和中期，主干经常不稳定。当我们到达α、β和最终发布的时候，事情完成了主干也就越来越稳定了。在发布不久前，主干变得近乎神圣。每个代码变更都要被小心的评估，以确保我们不会倒退。

At the moment of release, a branch gets created.  This branch becomes our maintenance tree for that release.  Our current maintenance branch is called "3.0", since that's the current major version number of our product.  When we need to do a bug fix or patch release, it is done in the maintenance branch.  Each time we do a release out of the maintenance branch (like 3.0.2), we apply a label.

发布的时刻，一个分支被创建。这个分支被变成了我们为那次发布建立的维护树。我们的当前维护分支被称为“3.0”，也是当前我们产品的主版本号。当我们需要修复一个缺陷或者为发布打补丁的时候，都在维护分支进行。每次我们做一次维护分支（例如3.0.2）的发布，我们就应用一个标签。

After the maintenance branch is created, the trunk once again becomes "basically unstable".  Developers start adding the risky code changes we didn't want to include in the release.  New feature work begins.  The cycle starts over and repeats itself.

在维护分支被创建之后，主干又变得“基本不稳定”。开发人员开始提交我们不希望包含在发布中的危险的代码变更。新特性开始工作。整个周期开始自己的循环往复。

When to branch?  Part 1:  Principles

什么时候分支？第一部分：原则

Best Practice: Don't create a branch unless you are willing to take care of it.
最佳实践：除非你乐意好好照顾它，否则，不要创建一个分支
A branch is like a puppy.

分支像一个小动物。

Your decisions about when to branch should be guided by one basic principle:  When you create a branch, you have to take care of it.  There are responsibilities involved. 

你决定什么时候进行分支都基于一个基本原则：当你创建一个分支，你必须要小心。这里是有责任在里面的。

• In most cases, you will eventually have to perform one or more merge operations.  Yes, the SCM tool will make that merge easy, but you still have to do it.
• If a merge is never necessary, then you probably have the responsibility of maintaining the branch forever. 
• If you create a branch with the intention of never merging to or from it, and never making changes to it, then you should not be creating a branch.  Use a label instead.
• 多数情况下，你最终会执行一个或更多的合并操作。是的，源码控制工具将容易的合并，但是你还是要亲自去做。
• 如果不需要合并，那你可能就要有永远维护分支的责任。
• 如果你创建分支的目的是永不合并，或不对其作变更，那你就不应该创建一个分支。使用一个标签来替代。

Be afraid of branches, but not so afraid that you never use the feature.  Don't branch on a whim, but do branch when you need to branch.

小心分支，但是不要害怕到永远都不用它。不要随性的做分支，但是在需要分支的时候就要分支。

When to branch?  Part 2:  Scenarios

什么时候分支？第二部分：场景

There are some situations where branching is NOT the recommended way to go:

有的情况不推荐分支：

• Simple changes.  As I mentioned above in my "Eddie" scenario, don't branch for every bug fix or feature.
• Customer-specific versions.  There are exceptions to this rule, but in general, you should not branch simply for the sake of doing a custom version for a specific customer.  Find a way to build the customizability into your app.
• 简单的变更：如我在我的“Eddie”的场景提到的，不要为每个缺陷修复或新特性进行分支。
• 用户定制版本：对这个规则有例外，但是，通常，你应该不要为了给一个指定的用户开发一个客户版本就简单的创建分支。找一种方式将定制构建到你的程序中去。

And there are some situations where branching is the best practice:

还有一些情况下分支是最好的方式：

• Maintenance and development.  The classic example, and the one I used above in my story about UltraHello.  Maintaining version N while developing version N+1 is the perfect example of a time to use branching.
• Subteam.  Sometimes a subset of your team needs to work on something experimental that will take several weeks.  When they finish, their work will be folded into the main tree, but in the meantime, they need a separate place to work.
• Code promotion.  If you want to use the dev-test-prod methodology I mentioned above, use a branch to model each of the three levels of code promotion.  
• 维护和开发：典型的例子，我前面在我的故事里面提到的UltraHello。一边维护版本N一边在开发版本N+1就是使用分支的时刻。
• 子项目组：有时候项目团队中的一个小组需要花几个星期做点实验性质的项目。当他们完成的时候，他们的工作就会加入到主干上，但是其间，他们需要一个单独工作的地方。
• 代码升级：如果你想使用我前面提到的开发－测试－产品化方法，那就需要在代码升级的三级中都建立分支。

When to branch?  Part 3:  Pithy Analogy

什么时候分支？第三部分：精练的类推

• A branch is like a working folder for multiple people.
• A working folder facilitates parallel development by allowing each person to have their own private place to work.
• When multiple people need a private place to work together, they need a branch.
• 一个分支类似给很多人的工作目录
• 通过允许每个人都有自己的地方工作，工作目录使得并行开发很容易了。
• 当很多的人需要独自的地方来一起工作，他们需要一个分支。

Looking Ahead

前瞻

In the next chapter I will delve into the topic of merging branches.

 下一章我会深入研究合并分支。