17

在 SVNtrunk中，推荐用于主要开发的地方，我在所有项目中都使用这个约定。但是，这意味着主干有时不稳定，甚至损坏。例如，当

  • 我犯了错误
  • 当由于 SVN 的工作方式而不得不破坏主干时。典型示例是文件重命名 - 您必须先提交任何文件重命名，然后再进行任何进一步的修改；但是，文件重命名可能需要代码重构以反映命名空间或类名更改，因此您基本上需要分两步提交单个逻辑操作。并且构建在步骤 1 和 2 之间中断。

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

4

10 回答 10

25

您的主干应该始终编译，如果您需要进行重大更改，您应该使用分支并稍后合并更改。

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

于 2008-09-30T16:21:10.837 回答
11

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

摘自文章：

有主线。“主线”或“主干”是永远发展的代码线的分支。主线为几乎所有更改（包括维护修复和新功能）提供了最终目的地，并且代表了软件产品的主要线性演变。发布代码线和开发代码线从主线分支，分支中发生的工作被传播回主线。

编辑：我还建议阅读SCM Patterns。

于 2008-09-30T16:21:32.677 回答
11

这真的取决于你的环境。在某些情况下，暂时损坏后备箱并不是什么大问题。但是，如果您与超过 2-3 人一起工作，那可能不是一个好主意。

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

当然，如果您的所有开发人员都在使用同一个分支，您将不会真正获得任何东西 - 您只会将您的主干称为 /branch/dev，但它的损坏仍然是一个主要问题！分解分支，这样每个分支只有少数开发人员工作，你应该很好。

于 2008-09-30T16:23:25.013 回答
6

主干是正在进行的开发应该发生的地方。如果每个人在提交更改之前都在测试他们的更改，那么您真的不应该对“损坏”的代码有问题。一个好的经验法则是在对更改进行编码后进行更新（从存储库中获取所有最新代码）。然后构建并进行一些单元测试。如果一切都构建并正常工作，那么您应该很好地检查它。

当你准备好发布时，创建一个分支。测试可以针对分支进行发布验证。如果发现问题，则对树枝和树干进行修复，并重新切割树枝进行测试。与此同时，开发人员正忙着为主干添加新的变化。

所以......通过测试发现的问题以及这些琐碎问题的出色解决方案在分支和主干中都是当前的，测试人员有一个稳定的工作范围，并且在测试验证当前版本的同时开发继续前进。

就像 Hanibal 在“The A-Team”中经常说的那样，“我喜欢当一个计划达成时。”

于 2008-09-30T16:50:43.527 回答
3

使用 Subversion 的团队通常对合并有病态的厌恶，因为在 1.5 之前，这是一个漫长而复杂的过程，容易失败。如果你有足够多的开发人员，那么拥有一个始终工作的主干是绝对必要的，因为许多人正在开发许多协同工作的不同模块，那么分支开发肯定会有所帮助。

顺便说一句，即使您重命名文件，您仍然可以编辑它。我一直这样做。

于 2008-09-30T16:50:54.773 回答
2

我创建了几个 shell 脚本来简化创建短期开发分支的过程：

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

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

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


# Switch to a branch or tag
function svn_switch()
{
  d=$1; shift
  REPO=$(svn info . | sed -ne 's@Repository Root: \(.*\)@\1@p')
  URL=$REPO/$d
  svn switch $URL
}
于 2008-09-30T18:27:02.733 回答
1

在我们公司，我们每晚都会构建一个后备箱。预计每个人都测试他们的代码，以便在签入之前至少可以编译。如果夜间构建失败，则会删除有问题的代码，直到修复为止。

我认为最重要的部分是让每个人都了解颠覆的作用以及为什么他们只签入可编译的代码很重要。

于 2008-09-30T16:35:35.530 回答
1

不，后备箱不是最好的地方。在我们的组织中，我们始终遵循这种方法：Trunk 包含发布代码，因此它始终可以编译。随着新的每个版本/里程碑，我们打开一个新的分支。每当开发人员拥有一个项目时，他/她都会为该发布分支创建一个新分支，并仅在对其进行测试后将其合并到发布分支中。发布分支在系统测试后合并到主干。

附图是粗略的表示。替代文字

于 2008-09-30T16:49:40.050 回答
1

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

我们在开发分支上工作，即分支/特性1，并通过复制分支/特性1->标签/特性1-qa1创建一个qa标签，并修复分支/特性1中的任何错误以创建标签/特性1-qa1等等。当准备好部署时，自上次合并到主干后在分支/功能 1 中发生的所有更改都将在创建最终发布标签（即 tags/5.1.0）之前合并回主干。

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

于 2009-06-17T07:41:19.643 回答
1

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

您正在开发一个依赖于大量实时数据（可能是用户贡献的数据）的 Web 应用程序。由于某种原因，您不仅可以生成另一个数据库后端（-s）实例或您所依赖的外部文件系统。（例如，您的环境可能缺少数据模型迁移）

A 团队一直在 /branches/F 中开发新功能 F。团队 B 刚刚启动了另一个分支来修复在 /branches/P 中的实时站点上发生的一些性能问题，团队 B 需要做的第一件事是重构一堆数据库表和/或文件在外部文件系统。这导致团队 A 必须重构他们的许多新东西才能继续开发。然后 C 队进来做另一件事……突然间，每个人都有一个问题。

然后是合并阶段——在那之后，没有人愿意再使用 TortoiseSVN。

于 2008-10-01T13:58:11.670 回答