如果您只有SVN分支，是否应该打扰一下？

如果我们仅在Subversion中使用一个分支，我们是否还要打扰？我们不能只在行李箱上工作以加快速度吗？

这就是我们使用Subversion开发的方式：

• 有一个行李箱
• 我们建立了一个新的发展分支
• 我们在该分支上开发了一项新功能
• 完成功能后，将其合并到主干中，删除分支，并从主干中创建新的开发分支

当我们要发布到生产环境时，我们会在行李箱中制作一个标签。错误修正是在该标签的分支上进行的。然后，此错误修正将合并到主干中。

这就是为什么在功能完成后我们创建了一个新的开发分支的原因。这样，错误修正会尽快包含在我们的新代码中。

下图应阐明：

现在，感觉这不是最有效的工作方式。我们在提交之前在本地进行构建，这大约需要5-10分钟。您可以理解，等待时间很长。

开发分支的想法是主干始终可以发布。但这在我们的情况下已不再是真的。有时，一项功能几乎已经准备就绪，并且一些开发人员已经开始编写下一个功能（否则，他们将围坐在一个或两个开发人员完成并合并的位置）。

然后，功能部件1完成后，将其合并到主干中，但包含功能部件2的某些提交。

那么，由于我们只有一个分支，我们是否应该还要烦扰开发分支？我一直在阅读有关基于主干的开发和逐个分支的信息，但是我发现大多数文章都集中在逐个分支的部分。我的印象是，重大变化将涉及多个版本。这不是我们遇到的问题。

你怎么看？我们可以在行李箱上工作吗？最坏的情况是（我认为），我们将不得不在主干中做一个标签，并挑选需要的提交，因为某些提交/功能尚未准备好投入生产。

如果您可以以较小的增量提交，并且已经进行了适当的集成，那么IMHO直接在主干上工作就可以了，因此您可以（在合理的范围内）确保提交不会破坏现有功能。我们在当前项目中也这样做（事实上，我默认情况下没有在任何使用特定于任务的分支的项目中工作）。

我们仅在发布前创建分支，或者仅在某个功能需要很长时间才能实现（即跨越多个迭代/发布）时才创建分支。任务的粗略大小几乎总是可以估算得足够好，以便我们提前知道是否需要单独的分支。我们还知道下一个版本（我们大约每2个月发布一次）之前还剩下多少时间，因此很容易看出任务是否适合下一个版本之前的可用时间。如果有疑问，我们可以将其推迟到创建release分支为止，然后可以在主干上开始工作了。到目前为止，我们只需要创建一个特定于任务的分支（大约3年）。当然，您的项目可能会有所不同。

功能开发所描述的是并行开发（针对不同产品版本的同时开发），并且确实需要分支机构才能正确处理。如果您经常不得不重新组合构成特定发行版的功能，则每个发行版或每个功能都可以有一个分支。

执行此操作的另一种方法是，默认情况下不使用主干，但是如果您希望任务扩展到下一个发行版，则创建一个分支。您总是标记发布的课程。

哪种方法真正取决于您可以预先进行多少管理。如果典型的发行版实际上没有并行开发，那么我将采用第二种方法。