什么是功能/错误发布的SVN最佳实践？

Question

我在StackOverflow上一直在阅读几个问题，但我并不满意。我所处的情况如下：

大型网络应用项目（复杂的部分，一些未知数）：

trunk 是主要的稳定版本

分支有错误发布，例如bug-503，bug-524，其中一些bug很复杂，涉及几个文件，其他的不是很多，有些是固定的，然后重新访问了几次。

标签我主要使用不同版本的标签，我们有三个环境：生产，沙箱和开发...标签发布有助于保持envs的修订号一致，以便在任何环境中给定时间我们可以比较环境使用的版本号

所以，我没有在分支机构中完成大部分工作，并将其合并回主干并生成标签版本。开发环境通常有一个包含所有最新错误修复/添加的构建。通常会对dev env进行审核，并且某些功能/错误被认为是稳定的，此时我将这些特定功能合并到主干中。对其他人进行了审核，可能还需要更多的工作，在这种情况下，我会进入特定的分支并进行调整。

我感觉到的痛苦是我有dev和trunk，我必须将功能/ bug分支合并到每个。看起来如此复杂和繁琐。 我做得对吗，有更好的方式/练习，更容易练习吗？或者我完全错了，在这种情况下我需要更好的方法！

Answer 1

我更喜欢这种情况：

• 开发trunk以进行微不足道的更改，或者在feature / bugfix分支中开发更大的工作。
• 还有环境分支和已发布的版本。例如“生产”，“舞台”
• 标签应该是最终的，即不提交标签。

所以，一个示例生命周期：

开发

• 在trunk中以及分支bug-1，bug-2，feature-1和feature-2中进行一些开发。验证错误和功能后，将稳定版本合并到主干中（例如合并bug-1，bug-2和feature-1）。

功能完成：

• 一旦准备好分阶段代码，您就可以将主干分支到分支“阶段”，以前在阶段的任何代码都将被主干代码替换。舞台系统始终运行舞台代码的构建，以便您可以进行测试。开发可以在主干和功能/ bug分支中继续。

推出：

• 一旦舞台分支足够稳定，您可以将其分支到发布分支。将其分支到名为“release-1.X”的分支，现在将此修订标记为“release-1.0.0”。生产服务器可以运行release-1.0.0标记的构建。不要对此标记提交任何内容。

修正：

• 如果您发现生产代码中存在错误，可以在主干中修复它，将修复程序通过各个阶段合并到1.X版本分支，然后将固定版本标记为1.0.1并指示生产服务器来运行这个新版本的构建。

Answer 2

说实话，你的练习对我来说似乎没问题，说过如果一个bug不会占用太多时间/代码那么我建议只需检查dev并在那里修复然后只是检查修复权限进入存储库开发。

还有一个原因需要一个始终稳定的行李箱吗？开发人员多久会打破你需要确保你总是有一个稳定的主干？您应该删除等式的开发部分，然后检查所有内容到主干中，然后确保主干在断开时尽快修复。这将使开发过程更加容易。只是想让你的生活更轻松。