我认为我做的不对。我正在使用颠覆作为我们组织网站的 vcs。我是唯一的开发人员，我使用 bugzilla 作为我的错误跟踪系统。我使用 bugtraq 属性将 bugzilla 和 svn 松散耦合，这样我就可以从我的 cmets 链接到 bugzilla。我现在正在做的是每当我收到在网站上执行任何工作的请求（增强、修复、内容更改）时，我都会在 bugzilla 中创建一个错误 [xx]，然后创建一个名为 bug[xx] 的分支。完成任务后，我手动将分支更改导出到我们的 beta 站点，对更改进行审查和验证，然后我将分支合并回主干，使用 bugtraq 属性指示错误#。
这很好用，除非我有不止一两个更改。如果我为 10 个工作请求创建了 10 个分支，我想知道如何轻松区分哪些已经合并到主干中，哪些没有。如果我应该使用看起来很疯狂的 mergeinfo 属性...
我不想从颠覆中切换，所以不建议这样做。
【问题讨论】：
标签： svn version-control branch bugzilla
当分支重新集成到主干中时，为什么不直接删除分支？当重新集成功能分支时，您应该做的事情（在一般情况下）。所以诊断很简单：如果分支存在，它还没有被重新集成。
【讨论】：
您的工作流程对我来说似乎相当不错。但是，合并回主干后，您不再需要错误分支，因此将其删除。这样一来，您只会将分支数量作为已打开的错误。
如果需要，您可以随时取回分支，但它不会把事情弄得一团糟。
【讨论】：
在我看来，为每个错误创建一个分支并不是一个好习惯。正如分支最佳实践所提到的，您应该在两种情况下创建分支：
看来你只需要第二个分支。为了更清楚，请看下面的图片：
开发分支是保存在您的主干目录下的分支（绿线）。您可以创建一个名为发布分支（红线）的分支，并将要发布的更改合并到其中。这样，只有选定的更改才会进入您的发布版本。如果您正在开发一个可能需要 1-2 周以上的新功能，请创建一个功能分支（蓝线）并在完成后合并回更改。功能分支完成后可能会被删除。
所以，我建议您只拥有一个称为发布分支的分支。当您收到错误时，请在您的开发线中进行更改。当测试正常时，您可以将更改合并回发布行。这样，您可以只发布您想要的那些功能。此外，通过查看您的发布行历史记录，您可以找到哪些更改已合并到您的发布行中。
【讨论】：