目前在我正在进行的项目中，我们只是放置了一个 TRUNK、TAG、BRANCH 结构来准备版本控制。由于大约有 10 名开发人员在处理不同的问题，我们想知道哪个应该是推进的最佳策略。
这个项目的一个特殊性是，在一天结束时，任何已解决的 ISSUE 必须在测试后部署到 INTEGRATION、HOMOL 和 PROD。
但我们正在讨论以我们可以选择必须提升哪个 ISSUE 的方式控制任何 ISSUE。
为每个 ISSUE 创建一个单独的 BRANCH 应该是解决方案吗？
我们是否应该为INTEGRATION保留一个BRANCH，HOMOL除了TRUNK来反映促销活动吗？
你们可以分享这个场景的一个众所周知的秘诀吗？
【问题讨论】：
标签： svn versioning
我不确定其他问题，但我认为答案是，
Should we maintain a BRANCH for INTEGRATION, HOMOL aside TRUNK to reflect the promotions?
是，不。我相信部署到初始环境的任何内容都应该部署到后续环境。我对“提升”的定义只是移动（二进制文件、安装程序、TAR 的 web 目录等），而不是为每个新环境检查和重建。
【讨论】：
如果我正确理解您的问题，我认为您是在问如何积极开发不稳定的更改，然后将更改标记为可供其他人使用。因此，您的存储库中需要一些始终“干净”的位置。
我已经看到了几种方法来做到这一点。一种方法是始终为每个 ISSUE 创建一个分支（我使用全部大写只是因为你在你的问题中做了，我真的不知道为什么）。一旦对 ISSUE 的修复程序完全编码、测试并可能经过同行评审，您就可以将 ISSUE 的分支合并回主干。使用这种策略，主干本身总是“干净”的，但会有很多合并。
我能立即想到的另一种方法是创建一个单独的“稳定”目录，在树干旁边或在分支目录中。当您感觉主干上的一组问题已准备就绪时，请对已准备好“稳定”的问题进行挑选合并。现在稳定目录总是“干净的”，但主干可能有正在进行的工作或损坏的东西。这种方式的合并较少，因为您可以分批进行，但它可能需要更多的工作来跟踪哪些更改实际上包含在 stable 中，哪些不包含，并且精选合并的性质意味着您可能会因为离开而破坏某些东西在您未合并的修订中删除所需的更改。
【讨论】：