在 Subversion 中管理分支

Question

我不认为我做的事情是正确的。我正在使用 Subversion 作为我们组织网站的 vcs。我是唯一的开发人员，我使用 bugzilla 作为我的错误跟踪系统。我使用 bugtraq 属性将 bugzilla 和 svn 松散耦合，这样我就可以从我的评论链接到 bugzilla。我现在正在做的是，每当我收到在网站上执行任何工作的请求（增强、修复、内容更改）时，我都会在 bugzilla 中创建一个错误 [xx]，然后创建一个名为 bug[xx] 的分支。完成任务后，我手动将分支更改导出到我们的测试站点，对更改进行审核和验证，然后我将分支合并回主干，使用 bugtraq 属性指示 bug#。

这非常有效，除非我有不止一两个更改。如果我为 10 个工作请求创建了 10 个分支，我想知道如何轻松判断哪些分支已经合并到主干中，哪些没有合并到主干中。如果我应该使用看起来很疯狂的 mergeinfo 属性...

我不想从 subversion 切换，所以不建议它。

Answer 1

当分支重新集成到主干中时，为什么不删除它呢？当功能分支重新集成时，您应该做什么（在一般情况下）。因此诊断很简单：如果分支存在，则它尚未重新集成。

Answer 2

你的工作流程对我来说似乎很不错。但是，合并回主干后，您不再需要该 bug 分支，因此将其删除。这样，您将只拥有作为打开的错误的分支数量。

如果需要的话，你可以随时取回分支，但它不会把事情弄乱。

Answer 3

从我的角度来看，为每个错误创建一个分支并不是一个好的做法。正如分支最佳实践提到的，您应该在两种情况下创建分支：

1. 当您正在开发可能需要很长时间的新功能时（功能分支）和
2. 当您想要保留最后发布的版本时（发布分支）。

看来你只需要第二个分支。为了更清楚地看一下下面的图片：

开发分支是保留在你的 trunk 目录（绿线）。您可以创建一个名为发布分支（红线）的分支，并将要发布的更改合并到其中。这样，只有选定的更改才会进入您的发布版本。如果您正在开发一项新功能，可能需要 1-2 周以上的时间，请创建一个功能分支（蓝线），并在完成后合并回更改。功能分支完成后可能会被删除。

因此，我建议您只有一个分支，称为发布分支。当您收到错误时，请对您的开发线进行更改。当测试正常后，您可以将更改合并回发布行。这样，您就可以只发布您想要的功能。此外，通过查看您的发布线历史记录，您可以找到哪些更改已合并到您的发布线中。