在SVN中，trunk是主要开发的推荐位置，我在所有项目中都使用此约定。但是，这意味着树干有时不稳定，甚至断裂。例如，当

• 我犯错了
• 当仅仅因为SVN的工作方式而不得不折断后备箱时。典型的例子是文件重命名-我们必须首先提交任何文件重命名，然后再进行任何进一步的修改；但是，文件重命名可能需要代码重构以反映名称空间或者类名称的更改，因此，我们基本上需要分两步提交单个逻辑操作。并且在第1步和第2步之间中断了构建。

我可以想象会有工具来防止错误地提交某些东西(例如，TeamCity和延迟的提交)，但是我们真的可以克服第二个问题吗？如果不是，那么在/ branch / dev这样的分支上进行"狂野开发"并仅在构建合理可靠时才合并到主干中会更好吗？

解决方案

主干应始终进行编译，如果我们需要进行重大更改，则应使用分支并将其合并回去。

阅读SVN书籍的这一章：http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html

我建议阅读这篇有关SCM最佳实践的文章。

从文章中摘录：

Have a mainline. A "mainline," or "trunk," is the branch of a codeline that evolves
  forever. A mainline provides an ultimate destination for almost all changes - both 
  maintenance fixes and new features - and represents the primary, linear evolution of a 
  software product. Release codelines and development codelines are branched from the 
  mainline, and work that occurs in branches is propagated back to the mainline.

编辑：我也建议阅读SCM模式。

这确实取决于环境。在某些情况下，暂时断开后备箱不是什么大问题。但是，如果我们与2至3个以上的人一起工作，那可能不是一个好主意。

在那种情况下，我认为更自由地使用分支是一个好主意。它们很容易设置和重新合并(如果我们不让事情变得太不同步)。

当然，如果我们所有的开发人员都使用同一个分支，我们将不会真正获得任何收益，只是将中继称为/ branch / dev，但将其断开仍然是一个主要问题！分解分支，以便每个分支上只有几个开发人员，而我们应该很好。

在我们公司中，我们每晚都有行李箱。期望每个人都对其代码进行测试，以便至少在他们签入之前进行编译。如果夜间构建失败，那么将删除有问题的代码，直到修复为止。

我认为最重要的部分是每个人都应了解Subversion的作用，以及为什么仅检查可编译的代码很重要。

没有行李箱不是最好的地方。
在我们的组织中，我们始终遵循以下方法：
Trunk包含发行代码，因此它总是可以编译。
有了新的每个发行版/里程碑，我们将打开一个新分支。
每当开发人员拥有某个项目时，他/她都会为该发行分支创建一个新分支，并且仅在对其进行测试之后才将其合并到发行分支中。
系统测试后，Release分支将合并到中继中。

所附图片是粗略的表示形式。替代文字http://i36.tinypic.com/2jvbs8.jpg

主干是正在进行的开发应该发生的地方。如果每个人都在提交更改之前测试了更改，那么我们实际上应该对"中断的"代码没有任何问题。一个好的经验法则是在对更改进行编码后进行更新(从存储库中获取所有最新代码)。然后构建并进行一些单元测试。如果一切都可以正常工作，那么最好将其签入。

准备发布时，请创建一个分支。测试可以针对分支机构进行发布验证。如果发现问题，则对分支和主干进行修复，并给出分支的新剪切进行测试。同时，开发人员正忙于向中继添加新更改。

因此...测试发现的问题以及针对这些琐碎问题的绝妙解决方案在分支机构和主干中都是最新的，测试人员可以稳定使用，并且在测试验证了当前版本的同时，开发工作仍在继续进行。

就像哈尼拔(Hanibal)在" The A-Team"上总是说的那样，"当计划达成时，我会喜欢的。"

使用Subversion的团队通常对合并有一种厌恶的态度，因为在1.5之前，它是一个漫长而复杂的过程，容易失败。如果我们有足够的开发人员，并且由于许多人正在一起工作的许多不同模块上而使中继线始终正常工作是绝对必要的，那么分支开发无疑会有所帮助。

顺便说一句，即使重命名文件，也仍然可以对其进行编辑。我一直都这样。

我创建了一些shell脚本来简化创建短暂的开发分支的过程：

# Create new branch and switch to it
function svn_bswitch()
{
   branch=; shift
   msg=""; shift

   URL=$(svn info . | sed -ne 's@URL: \(.*\)@@p')
   REPO=$(svn info . | sed -ne 's@Repository Root: \(.*\)@@p')
   BRANCH_URL=$REPO/branch/$branch

   svn copy $URL $BRANCH_URL -m "$msg"
}

# Switch to a branch or tag
function svn_switch()
{
  d=; shift
  REPO=$(svn info . | sed -ne 's@Repository Root: \(.*\)@@p')
  URL=$REPO/$d
  svn switch $URL
}

当旧的"稳定的主干，分支中的开发"过程成为问题时的另一个示例：

我们正在开发一个依赖大量实时数据(可能由用户提供)的Web应用程序。由于某种原因，我们不仅可以生成数据库后端的另一个实例或者我们所依赖的外部文件系统。 (例如，环境可能缺少数据模型迁移)

团队A一直在/ branches / F中开发新功能F。团队B刚刚启动了另一个分支，以解决在/ branches / P中的实时站点上发生的一些性能问题，团队B首先要做的是重构一堆数据库表和/或者文件在服务器上的布局方式。外部文件系统。这导致团队A必须重构他们的许多新内容，然后才能继续开发。然后C队进来做另一件事...突然每个人都遇到了问题。

然后进入合并阶段，此后再也没有人想要使用TortoiseSVN。

不，主干不是提交开发级别代码的最佳位置。在我们的环境中，我们将主干视为已部署到生产中的任何事物的镜像。 Web开发和应用程序开发的工作流程可能有所不同，但主干应包含最新的生产更改。

我们在开发分支(即branch / feature1)上进行工作，并通过复制branch / feature1->标签/ feature1-qa1创建一个qa标签，并修复branch / feature1中的所有错误以创建标签/ feature1-qa1，依此类推。准备好部署时，自从上次合并到主干以来分支/功能1中发生的所有更改都会在创建最终发行标签(即标签/5.1.0)之前合并回主干。

工作流程可能会有所不同，具体取决于团队的设置方式或者我们所处的项目/环境的类型。