0

我们的开发分支对我们的代码进行了多次修订。所以它看起来像：

发展

      R1.0
      R2.0
      R3.0
      Rx

我们正在同时开发多个版本。因此，A 团队将致力于 R2.0，而 B 团队将致力于 R3.0。虽然团队 A 在 R2.0 中进行更改，但我们需要确保这些更改反映在 R3.0 中。如果开发人员尝试将文件签入到 R2.0，是否有办法要求他/她将文件签入到 R3.0？

2013 年 8 月 1 日编辑

在阅读了几篇关于分支和合并策略的文章之后，我对我们应该如何处理这个问题有了一个想法。我只是想通过你运行它并询问我是否朝着正确的方向前进。因此，我们应该有一个主（开发）分支，然后在每个版本中从它分支出来，而不是拥有开发分支和版本副本。然后，按照我们的分支和合并策略中定义的频率，将 R1.0 和 R2.0 分支中的更改合并回主分支。当我们想要在 R3.0 上工作时，我们将所有 R1.0 和 R2.0 重新合并到 MAIN，然后从 MAIN 创建一个新分支。然后，假设我们需要 R1.0 的修补程序，我们从 R1.0 创建一个 R1.1，并将其合并回 R1.0，然后合并到 MAIN，然后从 MAIN 合并到 R2.0 和 R3.0。当我们同时处理新版本时，我们只保持 MAIN 与我们的下一个版本一样最新。因此，如果 R1.0 已经发布，那么 MAIN 应该与 R2.0 分支保持同步，因为它将是下一个版本。如果我错了，请纠正我并指出正确的方向。我是分支和合并的新手。

4

2 回答 2

2

您应该使用分支来管理版本之间的更改，而不是在同一分支中具有相同代码的不同版本。

即 R2.0 和 R3.0 都是您的主（或主干）分支的子分支。然后，您可以合并从 R2.0 到 Main 到 R3.0 的更改

阅读ALM Rangers指南以获取有关分支策略的更多信息

于 2013-08-01T11:14:01.107 回答
1

我喜欢你的想法，我认为它肯定会解决你的问题。我们正在做类似的事情，只是我们在 Main 和 Releases 之间有一个合并分支（中间分支）。

主要 -> 中级 -> R1

主要 -> 中级 -> R2

主要 -> 中级 -> R3

此选项的优点是：

  1. 您不必对 Main（主干）进行所有更改，Main 将保持清晰，并将充当您的 GOLDEN 产品，如代码。
  2. 为您的黄金代码添加另一层保护。假设 R3 分支刚刚从 Intermediate 创建，但此时 R2 决定放弃它的发布。在这种情况下，如果您使用中间分支（此时有 R1 + R2），那么您可以删除中间分支并从 Main（只有 R1）分支来创建一个新的中间分支（而不是回滚你的方法的变化）。然后从新的 R3 开始。

只是我的$0.02

于 2013-08-01T14:25:34.443 回答