【发布时间】：2014-06-06 12:56:29
【问题描述】：
在我们的开发过程中存在一个“问题”（实际上是一个令人讨厌的问题，但却是一个主要问题）。
我们已经建立了一个良好的持续集成-部署-交付管道；基本上，我们的流程是这样的：
新的开发发生在 default 分支上（我们使用 Mercurial，但 git 会有同样的问题）；通常我们只在那里开发一个小的改进；
一旦改进准备就绪并经过测试（通常每周发生两次或三次，我们的周期很短），它就会合并到 release 分支（实际上代表 候选版本），它会在类似生产的环境中再次进行测试，如果它通过了我们所有的测试，它就会被推送到生产环境。
如果我们需要修复错误，我们会在发布分支上进行，我们对其进行测试，然后将其推送到生产环境。
从每个分支构建一个工件（通常是一个 RPM 包）；当生产中发布时，来自发布分支的工件将被提升到我们的公共存储库。生产环境没有分支，因为我们通常不需要它（有很短的时间跨度在发布分支上但它不在生产环境中；代码不会在无人看管的情况下徘徊在那里）。
在这种情况下，我们有一个小问题。
为了区分包，我们通常将release分支上的包设置为1，默认分支上的包设置为2。然后我们的 CI 系统添加了它的内部版本号，所以我们有像 oursoftware-1.0-build37 这样的软件包用于发布，而 oursoftware-1.0-build902 是默认的。这样的版本要么写在我们的 .spec 文件中，要么写在我们的 pom.xml 文件中（或用于不同软件的其他文件，如 .gemspec 或 simila）
每当我们想在候选发布中添加一些东西时，我们都会将默认分支合并到发布分支。
那里会发生什么？ 版本也会合并。所以每次合并后，我们需要返回包含版本的文件并将旧版本放入其中。我们应该只需要做一次（Mercurial 不会尝试重新合并已经合并的东西）但是每当我们需要从默认版本中进行合并时（例如，为了将发布时完成的修复合并到 dev 分支) 问题又出现了。
我想要一些关于如何完全防止这个问题的建议； 如何在我的分支之外设置版本？ 我有时确实需要更改它们（例如，我想在发布时从 1 更改为 2，在默认情况下从 2 更改为 3）但我不喜欢为了在我们的 CI 系统中对它们进行硬编码，我想要一些“超出”分支范围的系统，它对于存储库来说有点“全局”。或者我需要“忽略对某些文件的修改”之类的东西。
在许多情况下，我实际上也需要文件中的版本；例如，我不能从 Maven pom.xml 文件或 .gemspec 中省略版本信息，否则在开发时将不起作用。
谢谢，
【问题讨论】：
标签： version-control mercurial continuous-integration dvcs continuous-deployment