有一个＆＃34;问题＆＃34; （实际上是一种令人讨厌的，但却是一种主要的）与我们的发展过程。
我们已经建立了良好的持续集成 - 部署 - 交付管道;基本上，我们的过程是这样的：
新的开发发生在默认分支上（我们使用Mercurial，但git会有同样的问题）;通常我们只在那里发展一个小改进;
一旦改进准备好并经过测试（通常每周发生两次或三次，我们的周期很短），它就会合并到发布分支（实际上是对于候选版本），它在类似生产的环境中再次进行测试，如果它通过我们所有的测试，它就会被推送到生产环境。
如果我们需要修复错误，我们会在发布分支上执行此操作，然后对其进行测试，然后将其推送到生产环境。
从每个分支构建工件（通常是RPM包）;当生产中有一个版本时，发布分支中的工件将被提升到我们的公共存储库。生产环境没有分支，因为我们通常不需要它（当发布分支上的某些内容出现时，它的时间跨度非常短但是它不在生产;代码不会在无人看管的情况下徘徊。
在这种情况下，对我们来说这是一个小问题。
为了区分软件包，我们通常将发布分支上的软件包的版本设置为1，将默认分支上的软件包的版本设置为2。然后我们的CI系统会添加其内部版本号，因此我们已经发布了 oursoftware-1.0-build37 发布的软件包以及默认情况下 oursoftware-1.0-build902 。这样的版本可以写在我们的.spec文件或我们的pom.xml文件中（或者用于不同软件的其他文件，如.gemspec或simila）
每当我们想要在发布候选版本中添加一些内容时，我们就会将默认分支合并到发布分支。
那里发生了什么？ 版本也会合并。因此，在每次合并之后，我们需要返回包含该版本的文件并将旧版本放入其中。我们应该只需要执行一次（Mercurial不会尝试重新合并已经合并的内容）但是每当我们需要从默认版本进行合并时（例如，为了将在发布时完成的修复合并到dev分支） ）问题再次出现。
我想就如何彻底预防这个问题提出一些建议; 如何在我的分支机构之外设置版本？我有时实际上需要更改它们（例如，我希望在发布时从1更改为2，默认情况下从2更改为3）并且我不会＆＃39;我想在我们的CI系统中对它们进行硬编码，我喜欢一些外部＆＃34;外部＆＃34;分支机构的范围及其类型的全球＆＃34;对于存储库。或者我需要类似＆＃34;忽略某些文件的修改＆＃34;。
在许多情况下，我实际上也需要我的文件中的版本;例如，我不能从Maven pom.xml文件或.gemspec中省略版本信息，否则它在开发时不会起作用。
谢谢，
答案 0 :(得分：0)
好吧，我看到 3 4 很多可能的解决方案，或多或少＆＃34; native＆＃34; （没有优先权和个人偏好的随机顺序）
internal:local特殊合并工具）