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

Question

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

3

我们正在考虑在我们的工作场所从SVN转换到分布式版本控制系统（DVCS）。

我很熟悉为什么想要在日常开发中使用DVCS的所有原因：本地版本控制，更容易的分支和合并等等，但是我还没有看到太多关于管理软件发布方面的有说服力的东西。以下是我们的发布流程：

- 发现可用于合并的变更。 - 运行查询以查找与这些变更相关联的缺陷/票证。 - 过滤与“打开”票证相关联的变更。在我们的环境中，必须关闭票证才能将其与发布分支合并。 - 过滤我们不希望出现在发布分支中的变更。当涉及到合并变更时，我们非常保守。如果一个变更不是绝对必要的，就不会被合并。 - 合并可用的变更，最好按时间顺序。如果它们与同一票证相关联，我们会将变更组合在一起。 - 阻止不需要的变更进入发布分支（svnmerge block），以便我们不必再次处理它们。

有时我们可能同时处理3-5个不同的里程碑。某些里程碑的约束条件非常不同，而屏蔽列表可能会变得相当长。

我已经在使用Git、Mercurial和Plastic，据我所知，它们都没有很好地解决这个模型。当你只发布一个产品时，它们似乎能很好地工作，但是我无法想象如何在同一代码库中处理多个非常不同的产品。

例如，在Mercurial中，挑选变更似乎是一个事后的想法。（您必须使用“移植”扩展，它默认处于禁用状态）。在将变更挑选到分支之后，它仍然显示为可用的集成。挑选变更会破坏Mercurial的工作方式。

DVCS似乎更适合特性分支。如果您直接从特性分支合并到主干和发布分支，则不需要挑选变更。但是，谁愿意一直进行所有这些合并呢？如何查询可用于合并的内容？如何确保特性分支中的所有更改都属于一起？这听起来像是完全混乱的。

我感到纠结，因为作为程序员，我希望在日常工作中使用DVCS。我真的很想要它。但是，我担心有一天我不得不戴上发布管理者的帽子，整理出需要合并和不需要合并的内容。我想写代码，我不想成为合并机器。

- See Sharp Cheddar

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Andrew McGregor · Accepted Answer

你在这种情况下真的应该使用Git，因为它在合并和发布管理方面非常出色。Git允许进行更改的签名流程才能发布；它实际上提供了多层次的发布管理支持，正是因为Linux就是这样管理的。

简单来说，每个发布都放在一个分支中。不要阻止你不想要的更改，只接受你想要的更改，通过仅对那些即将发布的更改进行签名来进行发布。

Git还允许您挑选一组更改并将其打包成单个补丁以发送到上游，因此您不必将所有“糟糕的，不太好用”的补丁带入发布分支或存储库中，只需要漂亮干净的功能或修复补丁即可。