产品发布标记的最佳实践

Question

我们有一个（历史上增长的）存储库结构（在我们的例子中使用Subversion），如下所示：

trunk/
  Product1/
  Product2/
  Product3/
  Product4/
  CommonDependencyOfProduct1and2/
  SomeStructuringFolder/
    CommonDependencyOfProduct1and3/
    CommonDependencyOfProduct2and3/
  ...

在为没有共享依赖项（Product4）的产品标记版本时，一切看起来都非常简单，我们只需从trunk / Product4创建一个标记并完成它。

但是，当我们发布其他产品之一时，我们还必须标记共享依赖项。我看到以下选项：

1. 创建整个存储库的标记
   • PRO：易于自动化，标签跟随主干结构
   • CON：将包括（不一定显然）不相关的产品，使得不清楚实际属于该版本的内容和不适用的内容（QA文档难看）。
2. 创建整个存储库的标记，然后删除所有不相关的文件夹
   • PRO：不包含不相关的代码，标签仍然遵循主干结构
   • CON：Afaik，修改标签仍然被认为是非常糟糕的做法。此外，它很难自动化（需要维护待保存或待移除产品的列表）。
3. 预先在tags /部分中创建一个新的空发布顶级文件夹，然后创建已发布项目及其所有依赖项的标记作为子文件夹
   • PRO：不包含不相关的代码，仍然相对容易自动化
   • CON：标签不再反映主干结构。此外，将不同部分复制到新文件夹仍可能算作修改标记。

第四个选择是将每个组件移动到一个单独的存储库，但对我们的基础架构会造成很大的破坏性，所以我想首先权衡替代方案。

同样的问题在某种程度上适用于创建工作分支。只有那里，我们通常不关心修改或包含不相关的代码，所以选项1或2通常是可以接受的。

Answer 1

这个怎么样：

1. 创建特定于产品的分支，例如/ branches / product1， / branches / product2等

2. 在这些分支上进行开发。每当释放一个 特定产品准备就绪，创建产品发布的标签 从分支，然后将该分支合并到/ trunk。这样你的行李箱会 总是有发布就绪的代码，没有不需要的代码。也 产品发布特定标签将来会派上用场。

3. 合并后，创建整个/主干的特定于发布的标签。

这可行吗？虽然它会增加分支之间频繁合并的开销。 正如您已经提到的，对于具有不同版本的产品，它总是更好地拥有不同的回购。它很容易扩展和自动化。