2

在此处输入图像描述

我在图片中添加了一个图例以使其不言自明。

最初，我的项目的主干代码是 1.0 版。

我将使用此版本的代码创建 4 个分支：Vendor-A、Vendor-B、1.1 和 1.2。红线代表这些并行开发分支。供应商特定的开发和发布在供应商分支上进行，供应商分支中的代码永远不会与主干合并。当向供应商发布版本时，这些版本会被标记。

现在，我的问题是：

  1. 这种产品开发方法的准确性如何？
  2. 比如说，将 1.1 代码合并到主干后，主干位于 1.1 和 1.1 分支结束（过期），之后我在 1.1 代码中发现了一个错误。现在，我会立即创建一个错误修复分支并将修复提交到主干。那么，是否应该将此错误修复推送到 1.2 分支和供应商分支？还是不应该推送它，因为这些分支正在处理不同版本的 Trunk (1.0)？
  3. 如何在供应商分支下解决开发问题？比如说，我需要修复 Vendor 分支中的错误，我应该直接将更改提交到 Vendor 分支吗？

我也会感谢您在重组/重新设计流程方面的建议。

4

1 回答 1

1

对我来说似乎没问题。但是，我会简化一点-如果我认为供应商分支从主干定期刷新是正确的，那么您不需要从错误修复分支进行显式合并-只需将错误修复（例如 1.1 错误修复）合并回主干，然后从主干合并到所有供应商分支。

从主干合并到供应商的技巧是准确跟踪已经合并的内容。理想情况下，您将合并所有内容，并按时间顺序分块进行。（我发现使用票证/功能编号标记提交很有用，因此我可以从svn log特定时间需要合并的内容中看到。这确保了我不会将半个功能发送到另一个分支。

当我提交合并时，我将添加合并字符串（例如“(merge -r1234:2345 -r2667:3123 ../../trunk)”以及合并的描述。这在查看时非常有用日志（比如在供应商分支上）以发现最早的未合并主干修订。

然而，我也倾向于在不同的分支上维护 1.0 和 1.1。因此，如果 1.1 分支合并后 1.0 主干变为 1.1，那么在此之前从主干获取分支 1.0 副本可能是合适的。最初，将对主干（1.1）进行错误修复，然后直接合并到从 1.1 分支派生的任何供应商。但是，它可能不适用于从 1.0 派生的供应商（或可能不相关）。在这种情况下，首先将它们应用到 1.0 分支，然后从那里合并到早期版本的所有供应商。

当然，您可能会发现仅与 1.0 相关的错误，并且在 1.1 中不相关或不存在 - 所以这个单独的分支也将在那里提供帮助。

考虑到这种方法，因此最好尽可能将每个供应商从非常旧的版本升级，从而最大限度地减少需要维护的并发版本的数量。无论您是理所当然地这样做，还是作为新许可/合同的一部分，都取决于您的业务。

于 2012-08-14T09:17:10.953 回答