所以这里是Subversion，Jenkins，Beanstalk设置：
基本上我想做的是：
这个想法是短暂的冲刺，在每个结束时，一个开发循环结束并且qa循环开始。当qa循环完成后，它将被推送到生产环境。
我想保留分支并从分支合并到\而不是删除和重新创建。这个想法是，在qa中进行的任何修复都将合并回介绍主干，并且在prod中进行的任何更改都将合并回qa（并返回到主干）。
因此，prod是一个“热门”分支，代表了生产环境的当前状态。这适用于一周开展短期冲刺的开发团队。
问题：
答案 0 :(得分：7)
我不推荐qa和prod分支。阅读颠覆最佳实践。我建议The SVN Book，特别是关于分支/合并的第4章。
即使是QA（通过标签），您也应该对每个版本进行版本控制。 Trunk用于当前的开发工作，标签用于已发布的版本（定义为“功能完整”，而不是它所处的环境），分支用于缺陷修复（除其他外）。
示例场景：
1.0版已投入生产，您的团队刚刚发布了2.0版QA进行测试，现在正在开发3.0版本。此时你将拥有：
如果您的QA团队在2.0中发现问题，您将创建2.0标记的分支。进行修复，合并到trunk然后将分支释放为2.0.1（另一个标记）。然后你将离开：
答案 1 :(得分：1)
我之前已经完成了一些关于分支和发布的类似工作，根据我的经验，你所描述的设置最终变得非常笨拙和官僚主义不久。
Domenic D.的答案非常接近我希望的那种设置，特别是对于少数开发人员。你拥有的分支越多，代码库的管理就越复杂，越有可能你是通过糟糕的合并做法引入错误。
有一件事你没有提到这一点很重要，在我看来，一开始就是你的办理登机手续。 SCM不是不完整工作的备份，您应该努力确保主线至少始终在构建。严格要求，最终会让每个人的生活更轻松。
但最重要的是，无论您采取何种释放程序，请确保您从团队中获得购买，并且不必将其“强制”到位。这表明你所提出的不正确可能会出现问题，很可能很快被忽视或被颠覆。