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

Question

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

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

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

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

我一直在搞git，mercurial和plastic，并且据我所知，他们都没有很好地解决这个模型。当你只有一种产品发布时，它们似乎能够很好地工作，但我无法想象使用它们来处理来自同一代码库的多种非常不同的产品。

例如，樱桃采摘似乎是mercurial中的事后考虑。 （你必须使用默认禁用的'移植'扩展名）。在选择分支后，它仍然显示为可用的集成。樱桃采摘打破了mercurial的工作方式。

DVCS似乎更适合功能分支。如果直接从功能分支合并到发行分支和，则无需进行樱桃选择。但是谁想要一直做所有的合并？你如何查询可用于合并的内容？您如何确保功能分支中的所有更改都属于同一个组织？这听起来像是一片混乱。

我很伤心，因为我的编码器需要DVCS进行日常工作。我真的很想要它。但是我担心那天我必须把发布经理的帽子弄清楚，并且要分清什么需要合并，哪些不合适。我想写代码，我不想成为合并猴子。

Answer 1

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

只需将每个版本放入分支。不要阻止你不想要的更改，只需接受你所做的更改，只需签署发布即将发布的更改即可。Git还允许你挑选一组更改为一个补丁发送到上游，所以你不必将所有'糟糕的，没有完全正常工作的'补丁放到发行版分支中或存储库，只有很好的清洁功能或修补程序。