在subversion中管理分支

Question

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

这非常有效除非我有一两个以上的更改。如果我为十个工作请求创建了10个分支，我想知道如何轻松地告诉哪些已经合并到主干，哪些不是。如果我应该使用似乎疯狂的mergeinfo属性......

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

Answer 1

为什么不将分支重新集成到主干中时删除分支？当你重新整合一个功能分支时你应该做的（在一般情况下）。所以诊断很简单：如果分支存在，它就没有重新整合。

Answer 2

您的工作流程似乎对我很好。但是，在合并回trunk后，您不再需要bug分支，因此请将其删除。这样，您只会将分支数量作为已打开的错误。

如果需要，你可以随时取回分支机构，但它不会让事情变得混乱。

Answer 3

从我的角度来看，为每个bug创建一个分支并不是一个好习惯。作为分支最佳实践提及，您应该在两种情况下创建分支：

1. 当您开发可能需要很长时间（功能分支）和
的新功能时
2. 当您想要保留上次发布的版本（Release Branch）时。

似乎你只需要第二个分支。为了更清楚，请看下面的图片：



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

所以，我建议你只有一个叫做发布分支的分支。收到错误后，请在开发线中进行更改。当测试正常时，您可以将更改合并回释放行。这样，您就可以释放所需的功能。此外，通过查看发布行历史记录，您可以找到已合并到发布行中的更改。