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

Posted 2023-03-06

【中文标题】什么是功能/错误发布的良好 SVN 最佳实践？

【英文标题】：What is a good SVN best practice for feature/bug releases?

【发布时间】：2011-10-04 15:19:20

【问题描述】：

我在 *** 上阅读了几个问题，但并不十分满意。我现在的情况如下：

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

trunk是主要的稳定版本

branches 有错误发布，例如bug-503、bug-524，其中一些 bug 很复杂，涉及多个文件，其他的则不是很多，有些得到修复，然后多次重新访问。

tags 我主要使用不同版本的标签，我们有三种环境：生产、沙盒和开发...给定时间，我们可以比较环境使用的版本号

所以我不是在分支中做很多工作，而是合并回主干并生成标签发布。开发环境通常具有包含所有最新错误修复/添加的构建。通常会对开发环境进行审查，并且某些功能/错误被认为是稳定的，此时我将这些特定功能合并到主干中。其他的经过审核，可能需要更多的工作，在这种情况下，我会进入特定的分支并进行调整。

我感到的痛苦是我有开发和主干，我必须将功能/错误分支合并到每个中。只是看起来如此复杂和繁琐。 我做得对吗，有没有更好的方法/练习，更容易练习？还是我做错了，在这种情况下我需要更好的方法！

【问题讨论】：

我需要某种方式来选择发布哪些错误/功能以及何时发布

【参考方案1】：

我更喜欢这种情况：

在主干中开发以进行琐碎的更改，或在功能/错误修复分支中进行更大的工作。 还有环境分支和发布版本。例如“制作”、“舞台” 标签应该是最终的，即不要提交标签。

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

发展

在主干和分支 bug-1、bug-2、feature-1 和 feature-2 中做一些开发。验证错误和功能后，将稳定的错误和功能合并到主干中（例如合并错误 1、错误 2 和功能 1）。

功能齐全：

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

发布：

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

修正：

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

【参考方案2】：

说实话，你的做法对我来说似乎很好，我说过如果一个 bug 不会花费太多时间/代码，那么我建议只检查开发并在那里进行修复，然后检查修复是否正确进入存储库开发。

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

【讨论】：

有时trunk会有bug-A、bug-B，而dev会有bug-A、bug-B、bug-C和feat-A

我明白你在说什么，但我不会犹豫将一堆东西扔进后备箱。也许你的测试有点缺乏，或者你们比我们更谨慎，但在大多数情况下，我会说只是将功能放在后备箱中，如果你破坏了它，请修复它。