我有一个用于Web应用程序的Kiln / Mercurial代码存储库，它使用Cruise Control.NET进行持续集成。通常，我们在本地提交代码，当我们准备好测试时，我们会推送到我们的中央Kiln服务器。 Cruise Control会定期检查该服务器上的存储库以获取新版本，当它找到它时，它会构建它并将生成的文件复制到适当的Web服务器。如果它测试了，我们然后手动强制构建到我们的主要生产服务器，一切都很好。
最近，我们遇到了一个小小的打嗝。我们在上个月推出到生产版本的版本中发现了一个错误，需要修复。自那时以来已经有50个左右的提交，并且在这50个提交中引入的代码远未准备好生产。我们知道我们可以在本地回滚（更新）到推出到生产的版本并修复代码但我们无法将其推送到Kiln并将其发送到Cruise Control - 在Kiln服务器上的Mercurial抱怨多个头。解决这个问题的最佳方法是什么？
我们已经google了一下，发现了对分支和标签的引用。我们最终在Kiln服务器上的存储库中创建了一个新分支。那个分支有我们的主存储库减去那50个提交。然后我们制作了我们的bugfix并编辑了Cruise Control配置，而不是主存储库。在一些构建之后，我们在生产服务器上修复了我们的错误。这似乎是回滚，修复并将其推送到Web服务器的大量工作。
由于我们是一家小商店，我们通常有自己的项目可供使用。虽然我们不是版本控制的新手，但是我们还没有故意分支（直到现在）甚至是最小的合并，但是我们还没有处理过这个概念的某些常见方面。
答案 0 :(得分：0)
您说您的代码中存在问题，之后您提交了大约50个提交。所以你创建了一个包含当前代码的分支--50次提交。
所以我的建议是它不应该是你的分支，但它应该只是Trunk。分支代码应包含主要更改的代码，即您在该代码中工作了很长时间，同时可能有机会在主干中执行某些代码并可以转移到生产中。
因此，在创建CI时，我的建议是分别为Trunk和branch设置CI，以便进行测试。
也只能从行李箱开始生产。