svn dev cycle。如何批准许多次要“功能”待批准

Question

我已经阅读了类似的问题，但仍然觉得有必要提问。 我有一些场景，我们有许多微小的“功能”等待批准。我通常会看到两种方法。

1.保持树干坚固，并为每个微小的“功能”提供大量分支。基本上每一件新东西都是分支。

缺点：
  - 无论变化多么小，都可能成为支持如此众多分支的梦魇。保持所有分支同步等等   - 最糟糕的是我在这里看到的是测试系统的设置，这样就可以轻松地检查批准的变化（基本上需要支持看起来很疯狂的所有分支）。

优点：
- 一旦批准将一个分支合并回主干和新版本进行标记和部署，看起来很简单。

2.对于大功能，分支被释放，对于小的改变，所有都直接进入主干（相对稳定）。

优点：
- 更容易设置测试系统，因为大多数时间都可以直接看到。对于大功能应该易于维护单独的分支测试 缺点：
- 不要真的看到释放将如何发展。我将无法基本上释放一部分树干这将涉及樱桃，这是疯狂的遵循。其他方法是我只是强制执行一段时间（一周左右）后，所有小功能都需要获得批准，以便在提供新任务之前部署它们。 我只是创建了发布分支，并且所有小功能都没有上线。这将与主管人员进行一些有趣的讨论。

我认为有很多小的待处理内容在技术上是非常有问题的。

Answer 1

我使用TFS，但策略是一样的。您的选项1是最干净的方法，但是许多分支的合并开销。这很好，因为您的主干没有被未经测试的代码和新分支污染，可以从稳定的代码库创建。您还可以从其自己的分支中释放每个功能以进行独立测试 如果您的更改非常小并且相互独立（即不影响相同的源文件），则可以应用的另一种方法是创建功能分支，然后标记（标记）该分支上的每个功能。因此，您可以获得用于构建和测试每个功能的标记版本。但随着越来越多的代码被更改，你必须定期摆脱这个分支。