功能/错误版本的SVN最佳实践是什么？

Question

我一直在StackOverflow上阅读几个问题，但我并不十分满意。我在这种情况如下：

大型Web应用程序项目（复杂的零件，几未知）：

干线是主要的稳定版本

分支有BUG的版本如bug-503，bug-524，其中一些错误是复杂的，涉及多个文件，其他错误不是很多，有些会得到修复，然后重新访问多次。

标签我主要使用的标签不同的版本中，我们有三种环境：生产，沙箱和DEV ...标签发行有助于保持一个版本号跨ENVS一致，以便在任何时候，我们可以比较环境正在使用的版本号

因此，我没有在分支机构中完成大部分工作，并合并回主干并生成标签发布。开发环境通常具有所有最新的错误修复/添加的构建。通常有关于开发环境的评论，某些特征/错误被认为是稳定的，此时我将这些特定功能合并到主干中。其他人被审查，可能需要更多的工作，在这种情况下，我会进入特定的分支并进行调整。

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

Answer 1

说实话你的做法对我来说似乎很好，说如果一个bug不会花费很多时间/代码，那么我会建议只检查一下dev并在那里做修复，然后检查修复版本库dev。

还有一个原因，你需要一个始终稳定的主干？开发人员多久开发一次，以确保始终拥有稳定的主干？你应该删除等式的开发部分，只是检查一切进入树干，然后确保树干如果损坏即时修复。这将使开发过程变得更容易。只是想让你的生活更轻松。

Answer 2

我更喜欢这样的场景：

• 开发树干为了微不足道的变化，或在较大件工作的一个特点/ bug修复分支。
• 也有环境分支和发布版本。例如“生产”，“阶段”
• 标签应该是最终的，即不要委托给标签。

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

发展

• 做一些developent在树干和树枝中的bug-1，错误-2，功能1和功能2。验证错误和功能后，将稳定的合并到主干中（例如合并bug-1，bug-2和功能-1）。

功能齐全：

• 一旦你准备阶段，你可以分支主干到分支“舞台”的代码，曾经是在舞台的任何代码将通过主干代码来代替。舞台系统总是运行阶段代码的构建，以便测试。发展可以继续在主干和功能/ bug分支。

发布：

• 一旦阶段分支足够稳定，您可以在跳转到发布分支。将它分支到名为“release-1.X”的分支，现在将该修订标记为“release-1.0.0”。生产服务器可以运行release-1.0.0标签的版本。不要对此标签提交任何内容。

修正：

• 如果您发现生产代码中的错误，你可以修复它的树干，在各阶段的合并修改到发布1.X分支，然后标记固定发布版本为1.0.1，并指示生产服务器运行此新版本的构建版本。