你什么时候应该分支？
使用 SCM 系统时，什么时候应该进行分支？
When working with a SCM system, when should you branch?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
使用 SCM 系统时，什么时候应该进行分支？
When working with a SCM system, when should you branch?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（12）
一般来说，分支（VCS - 版本控制系统 - 功能）的主要目的是实现代码隔离。
您至少有一个分支，这足以进行顺序开发，并且用于在同一唯一分支上记录（提交）的许多任务。
但该模型很快就显示出了它的局限性：
当您进行开发工作（重构、演进、错误修复等）并且您意识到您无法安全地在与当前开发分支相同的分支中进行这些更改时（因为您会破坏API，或引入会破坏一切的代码），那么您需要一个另一个分支。
（为了隔离旧代码的新代码，即使这两个代码集稍后将合并）
这就是您的答案：
只要您无法在一个分支中追求和记录两项开发工作，就应该进行分支。
（无需维护极其复杂的历史）。
即使您是唯一一个或多人处理源代码的人，分支也可能很有用。
但你不应该“每个开发人员一个分支”：
隔离的目的是隔离开发工作（一项任务可以像“让我们开发软件的下一个版本”一样笼统，也可以像“让我们修复错误 23"),
不隔离资源。
（名为“VonC”的分支对其他开发人员来说没有任何意义：如果“VonC”离开项目怎么办？你应该用它做什么？
例如，一个名为“bugfix_212”的分支可以在错误跟踪系统的上下文中进行解释，任何开发人员都可以使用它，至少对他应该用它做什么有一些了解）
分支不是标签 （SVN 是一个修订系统，尝试提出版本控制功能，例如分支和标记具有廉价文件副本的目录：这并不意味着标签是分支）
定义分支意味着还定义合并工作流程< /strong>：您需要知道完成分支后将其合并到哪里。
为此，《Practical Perforce》（Laura WINGERD - O'Reilly）的第 7 章是一个很好的介绍（与 VCS 无关），用于合并不同类型分支之间的工作流程：“
“软件如何发展” (pdf
)定义了术语代码线（分支，记录代码的重要演变步骤，通过某些点的标签，或者通过重要的合并回分支）
它引入了主线模型（记录发布的中央代码线） ），并描述了分支的各种目的：
这允许“尽早提交，经常提交”。
围绕 VCS 的其他有趣概念：基本概念
（最初是关于 ClearCase，但也适用于任何 VCS）
In general term, the main purpose of branching (a VCS - Version Control System - feature) is to achieve code isolation.
You have at least one branch, which can be enough for sequential development, and is used for many tasks being recording (committed) on that same unique branch.
But that model shows quickly its limit:
When you have a development effort (refactoring, evolution, bug-fixes, ...) and you realize you cannot safely make those changes in the same branch than your current development branch (because you would break API, or introduce code that would break everything), then you need a another branch.
(To isolate that new code for the legacy one, even though the two code sets will be merge later on)
So that is your answer right there:
You should branch whenever you cannot pursue and record two development efforts in one branch.
(without having an horribly complicated history to maintain).
A branch can be useful even if you are the only one working on the source code, or if you are many.
But you should not make "one branch per developer":
The isolation purpose is made to isolate a development effort (a task which can be as general as "let's develop the next version of our software" or as specific as "let's fix bug 23"),
not to isolate a resource.
(a branch called "VonC" means nothing to another developer: What if "VonC" leaves the project? What are you supposed to do with it?
a branch called "bugfix_212" can be interpreted in the context of a bug tracking system for instance, and any developer can use it with at least some idea about what he is supposed to do with it)
A branch is not a tag (SVN is a Revision System which tries to propose versioning features like branching and tagging through directories with cheap file copy: that does not mean a tag is a branch)
To define a branch means also defining a merge workflow: you need to know where to merge your branch when you are done with it.
For that, the chapter 7 of Practical Perforce (Laura WINGERD - O'Reilly) is a good introduction (VCS agnostic) to merge workflow between different kind of branches: "
"How Software Evolves" (pdf)
It defines the term codeline (branch which records significant evolution steps of the code, either through tags at certain points, or through important merge back to the branch)
It introduce the mainline model (a central codeline to record releases), and describes various purposes for branching:
That allows to "commit early, commit often".
Other interesting concepts around VCS: Basics concepts
(about ClearCase originally, but also valid for any VCS)
分支有多种用途。最常见的用途之一是分离曾经具有公共代码库的项目。这对于试验代码非常有用，而且不会影响主干。
一般来说，您会看到两种分支类型：
功能分支：如果某个特定功能具有足够的破坏性，您不希望整个开发团队在其早期阶段受到影响，您可以创建一个分支来执行 。
修复分支：在主干上继续开发的同时，可以创建修复分支来保存对软件最新发布版本的修复。
您可能有兴趣查看以下文章，其中解释了分支的原理以及何时使用它们：
There are several uses for branching. One of the most common uses is for separating projects that once had a common code base. This is very useful to experiment with your code, without affecting the main trunk.
In general, you would see two branch types:
Feature Branch: If a particular feature is disruptive enough that you don't want the entire development team to be affected in its early stages, you can create a branch on which to do this work.
Fixes Branch: While development continues on the main trunk, a fixes branch can be created to hold the fixes to the latest released version of the software.
You may be interested in checking out the following article, which explains the principles of branching, and when to use them:
所有 21 世纪的 SCM 都在告诉您：
为您必须处理的每项任务建立分支，无论这是新功能、错误修复、测试还是其他什么。这称为主题分支，它改变了您使用 SCM 的方式。
您将获得：
可以做到这一点的工具：
做不到的工具：
All the 21th century SCMs are telling you:
Branch for every task you've to work on, no matter whether this is a new feature, a bugfix, a test, whatever. This is called topic branch, and it changes the way you work with your SCM.
You get:
Tools that can do it:
Tools that CAN'T do it:
它还取决于您使用的 SCM 工具。现代 SCM（git、mercurial 等）使得在需要时创建和销毁分支变得越来越容易。例如，这允许您为您正在处理的每个错误创建一个分支。一旦将结果合并到主干中，就丢弃了分支。
其他 SCM，例如 subversion 和 CVS，具有“更重”的分支范例。这意味着，分支仅被认为适合大于二十多行补丁的内容。在那里，分支通常用于跟踪整个开发轨迹，例如之前或未来的产品版本。
It also depends on the SCM tool you are using. Modern SCMs (git, mercurial, etc.) make it increasingly easy to create and destroy branches whenever needed. This allows you to, for example, make one branch per bug that you are working on. Once you merge your results into the trunk, you discard the branch.
Other SCMs, for example subversion and CVS, have a much "heavier" branching paradigm. That means, a branch is considered appropriate only for something bigger than a twenty-something-line patch. There, branches are classically used to track entire development tracks, like a previous or future product version.
当您需要对代码库进行重大和/或实验性更改时，特别是如果您想提交中间更改而不影响主干。
When you need to make significant and/or experimental changes to your codebase, particularly if you want to commit intermediate changes, without affecting trunk.
这取决于您使用的 SCM 类型。
在较新的分布式版本（如 git 和 Mercurial）中，您一直在创建分支并无论如何重新合并。我经常会在一个单独的分支上工作一段时间，只是因为有人破坏了主线上的构建，或者因为网络故障，然后在修复后将更改合并回来，而且这很容易做到，甚至不会令人烦恼。
最能帮助我了解分布式系统中发生的情况的文档（简短易读）是： 了解Mercurial。
在具有中央存储库的旧系统中（例如 CVS、SVN 和 ClearCase），这是一个更严重的问题，需要在团队级别上决定，答案应该更像是“维护旧版本，同时允许开发继续在主线上”，或“作为重大实验的一部分”。
我认为分布式模型要好得多，并且只缺少漂亮的图形工具来成为主导范例。然而，它并没有被广泛理解，而且概念也不同，因此新用户可能会感到困惑。
It depends on what type of SCM you're using.
In the newer distributed versions (like git and mercurial), you're creating branches all the time and remerging anyway. I'll often work on a separate branch for a while just because someone's broken the build on the mainline, or because the network's down, and then merge changes back in later when it's fixed, and it's so easy to do that it's not even annoying.
The document (short and readable) that most helped me understand what was going in in the distributed systems is: UnderstandingMercurial.
In the older systems with a central repository, (like CVS, SVN and ClearCase), then it's a much more serious issue which needs to be decided at a team level, and the answer should be more like 'to maintain an old release whilst allowing development to continue on the main line', or 'as part of a major experiment'.
The distributed model is much better, I think, and lacking only nice graphical tools to become the dominant paradigm. However it's not as widely understood, and the concepts are different, so it can be confusing for new users.
我从劳拉·温格德 (Laura Wingerd) 和Perforce 的 Christopher Seiwald 确实简洁且有用：
请参阅 http ://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf 了解其中每一项以及其他最佳实践的详细说明。
I find the advice from Laura Wingerd & Christopher Seiwald at Perforce is really concise and useful:
See http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf for a detailed explanation of each of them and other best practice.
分支有多种目的：
There are various purposes for branching:
还可能出现分支的需要：
The need for branching may also arise:
当您需要根据当前分支进行更改时，而不是针对该分支的下一个版本（而不是之前）。
例如，我们通常在主干上工作。在发布前后，有人需要做出我们在当前版本中不希望发生的更改（可能是在发布之前，目前通常是在发布之后）。这是我们分支的时候，将版本放在自己的分支上，并继续在主干上开发下一个版本。
When you need to make changes, based on your current branch, not destined for the next release from that branch (and not before).
For example, we work on trunk usually. Around the time of release, someone's going to need to make a change that we don't want in the current release (it may be before release, at the moment it's usually after release). This is when we branch, to put the release on its own branch and continue development for the next release on trunk.
每当你愿意的时候。
如果您使用集中式 SCM，您可能不会经常这样做，因为分支是官方存储库的一部分，并且这并不会真正邀请太多实验，更不用说合并确实会带来伤害。
OTOH，分布式 SCM 中的分支和结帐之间没有技术差异，并且合并要容易得多。你会感觉更频繁地进行分支。
Whenever you feel like it.
You probably won't very frequently if you work with a centralized SCM since the branches are part of the official repository, and that doesn't really invite much experimentation, not to mention that merges really hurt.
OTOH, there's no technical difference between a branch and a checkout in distributed SCMs, and merges are a lot easier. You'll feel like branching a whole lot more often.
把所有的技术细节放在一边......
当你知道它更容易合并回来时进行分支！
请记住，合并始终会受到项目中工作的执行方式的影响。
一旦实现这一点，所有其他第三级问题都将发挥作用。
Leaving all the technicalities aside.....
Branch when you know its easier to merge back!
Keeping in mind that merging will always be effected with how the work is carried out in a project.
Once this achieved all the other tertiary issues will come in to play.