The company I work for is starting to have issues with their current branching model and I was wondering what different kinds of branching strategies the community has been exposed to?
Are there any good ones for different situations? What does your company use? What are the advantages and disadvantages of them??
这是我过去成功使用的方法：
/trunk - 最前沿。代码的下一个主要版本。在任何给定时间可能会或可能不会工作。
/branches/1.0、1.1等代码的稳定维护分支。用于修复错误，稳定新版本。如果是维护分支，它应该编译（如果适用）并在任何给定时间准备好进行 QA/运输。如果是稳定分支，它应该编译并且功能完整。不应该添加任何新功能，不应该重构，也不应该清理代码。您可以添加前缀来指示稳定分支与维护分支。
/分支机构/cool_feature。用于可能会或可能不会进入主干（或维护分支）的高度实验性或破坏性工作。不保证代码编译、工作或其他行为正常。在合并到主线分支之前应尽可能持续最短时间。
/tags/1.0.1、1.0.2、1.1.3a 等。用于标记打包和发布的版本。永远不会改变。制作尽可能多的标签，但它们是不可变的。
我们的存储库如下所示：
/trunk
/branches
/sandbox
/vendor
/ccnet
/trunk是您的标准、前沿开发。我们使用 CI，因此必须始终构建并通过测试。
/branches 这是我们进行“批准”的大更改的地方，即我们知道的东西会进入主干但可能需要一些工作并且会破坏 CI。也是我们在维护版本上工作的地方，这些版本有自己的 CI 项目。
/sandbox 每个开发人员都有自己的沙箱，外加一个共享沙箱。这适用于诸如“让我们将 LINQ 提供程序添加到我们的产品”类型的任务，您在不进行实际工作时执行这些任务。它最终可能会进入主干，也可能不会，但它在那里并且在版本控制之下。这里没有 CI。
/vendor 我们编译的项目的标准供应商分支，但它不是我们维护的代码。
/ccnet 这是我们的 CI 标签，只有 CI 服务器可以写在这里。后见之明会告诉我们将其重命名为更通用的名称，例如 CI、BUILDS 等。
看看这个http://codicesoftware.blogspot.com/2010/03/branching-strategies.html以获得更好的解释
第一件事：亲吻（保持简单愚蠢！）
/分支机构 /RB-1.0 (*1) /RB-1.1 (*1) /RB-2.0 (*1) /标签 /REL-1.0（或任何您的版本，例如 1.0.0.123 *2） /REL-1.1 /REL-2.0 /树干 当前开发具有很酷的新功能；-)
*1) 保持版本可维护 - 例如服务包、修补程序、错误修复，如果需要和/或需要，可能会合并到主干) *2) major.minor.build.revision
经验法则：
--hfrmobile
当发布准备好进行最终 QA 时，我们会进行分支。如果在 QA 过程中发现任何问题，则会在分支中修复错误，验证然后合并到主干。一旦分支通过了 QA，我们将其标记为发布。该版本的任何修补程序也会对分支进行、验证、合并到主干，然后标记为单独的版本。
文件夹结构如下所示（1 个 QA 行、2 个修补程序版本和主干）：
/分支机构
/REL-1.0
/标签
/REL-1.0
/REL-1.0.1
/REL-1.0.2
/树干
我们使用狂野、狂野、西方风格的 git-branch。我们有一些分支具有按惯例定义的众所周知的名称，但在我们的例子中，标签实际上对我们来说更重要，以满足我们的公司流程策略要求。
我在下面看到您使用 Subversion，所以我认为您可能应该查看Subversion Book中有关分支的部分。具体来说，请查看Branch Maintenance和Common Branch Patterns中的“存储库布局”部分。
我在这里没有看到的另一种选择是“变革分支”哲学。
如果后备箱是“当前版本”，而不是让您的后备箱成为“狂野西部”，该怎么办？当一次只发布一个版本的应用程序时，这很有效 - 例如网站。当需要新功能或错误修复时，会创建一个分支来保存该更改。这通常允许将修复程序迁移到单独发布，并防止您的牛仔编码员意外添加您不打算发布的功能。（通常是后门——“仅用于开发/测试”）
Ben Collins 的建议对于确定哪种风格适合您的情况非常有用。
Gnat就您可以找到的有关分支策略的各种建议编写了这篇出色的分解图。
没有一种分支策略，它适用于：
Jeff Atwood 的帖子打破了很多可能性。另一个要补充的是促销的概念（来自 Ryan Duffield 的链接）。在此设置中，您有一个 dev 分支、test bracnh 和 release 分支。你提升你的代码，直到它到达发布分支并被部署。
We currently have one branch for ongoing maintenance, one branch for "new initiatives" which just means "stuff that will come out sometime in the future; we're not sure when." We have also occasionally had two maintenance branches going on: one to provide fixes for what is currently in production and one that is still in QA.
The main advantage we've seen is the ability to react to user requests and emergencies more rapidly. We can do the fix on the branch that is in production and release it without releasing anything extra that may have already been checked in.
The main disadvantage is that we end up doing a lot of merging between branches, which increases the chance that something will get missed or merged incorrectly. So far, that hasn't been a problem, but it is definitely something to keep in mind.
Before we instituted this policy, we generally did all development in the trunk and only branched when we released code. We then did fixes against that branch as needed. It was simpler, but not as flexible.
The philosophy that we follow at work is to keep the trunk in a state where you can push at any time without drastic harm to the site. This is not to say that the trunk will always be in a perfect state. There will of course be bugs in it. But the point is to never, ever leave it broken drastically.
If you have a feature to add, branch. A design change, branch. There have been so many times where I thought, "oh I can just do this in the trunk it isn't going to take that long", and then 5 hours later when I can't figure out the bug that is breaking things I really wished that I had branched.
When you keep the trunk clean you allow the opportunity to quickly apply and push out bug fixes. You don't have to worry about the broken code you have that you conveniently branched off.
For Subversion, I agree with Ryan Duffield's comment. The chapter he refers to provides a good analyses on which system to use.
The reason I asked is that Perforce provides a completely different way to create branches from SVN or CVS. Plus, there are all the DVCSs that give it's own philosophy on branching. Your branching strategy would be dictated by which tool(s) you're using.
FYI, Svnmerge.py is a tool to assist with merging branches in SVN. It works very well as long as you use it frequently ( every 10-30 ) commits, otherwise the tool can get confused.
无论选择哪种分支模式，您都应该尝试将分支保持为二叉树形式，如下所示：
trunk - tags
|
next
/ \ \
bugfix f1 f2
/ \ \
f11 f21 f22