使用分布式版本控制系统进行发布管理

Question

我们正考虑在我的工作场所从SVN切换到分布式VCS。

我熟悉想要使用DVCS进行日常开发的所有原因：本地版本控制，更容易的分支和合并等等，但我还没有看到那么多的引人注目的管理软件版本。这是我们的发布流程：

• 了解可用于合并的更改。
• 运行查询以查找与这些更改相关的缺陷/故障单。
• 过滤掉与“开放”门票相关的更改。在我们的环境中，票证必须处于关闭状态才能与发布分支合并。
• 过滤掉我们在发布分支中不需要的更改。在合并变更方面，我们非常保守。如果不是绝对必要的更改，则不会合并。
• 合并可用的更改，最好按时间顺序排列。如果它们与同一张票相关联，我们会将更改分组。
• 阻止发布分支（svnmerge block）中的不需要的更改，以便我们不必再次处理它们。

有时我们可以一次处理3-5个不同的里程碑。一些里程碑具有非常不同的约束，并且阻止列表可能会很长。

我一直在搞乱git，mercurial和plastic，据我所知，他们都没有很好地解决这个模型。当你只发布一个产品时，它们看起来会很好用，但是我无法想象它们会用来处理来自相同代码库的多个非常不同的产品。

例如，樱桃采摘似乎是善变的事后想法。 （您必须使用'移植'扩展，默认情况下禁用）。在您选择更改为分支后，它仍然显示为可用的集成。樱桃采摘打破了善变的工作方式。

DVCS似乎更适合功能分支。如果直接从功能分支合并到主干和发布分支，则无需进行挑选。但是谁想要做所有那些一直合并的事情呢？你如何查询可以合并的内容？您如何确保功能分支中的所有更改都属于一起？这听起来像完全混乱。

我被撕裂是因为我的编码员想要DVCS进行日常工作。我真的很想要它。但是我担心有一天我必须把发布经理放在帽子上并理清需要合并的东西，什么不合并。我想编写代码，我不想成为合并的猴子。

Answer 1

你真的想在这种情况下使用git，因为它在合并和发布管理方面非常优越。 Git允许签署更改的签收过程;它实际上提供了对多层发布管理的支持，正是因为这是Linux的管理方式。

简单地将每个版本放在一个分支中。而不是阻止您不想要的更改，只接受您所做的更改，只需注销即将发布的版本中的更改。

Git还允许您将一组更改添加到上游发送的单个补丁中，这样您就不必将所有“oops，那些没有完全正常工作”的补丁包含在发布分支中或存储库，只有很好的清理功能或修复补丁。