我正在努力将我们的开发团队迁移到Subversion并改进我们的存储库结构和流程。我们基本上采用标准的trunk / branches / tags设置。我原本打算使用发布分支策略（branches / 1.0，branches / 2.0等），但现在我倾向于代码推广模型（测试和生产分支）。对于我们团队的工作方式来说，它会更好一些，更直观，但是发布会不那么简单：我们有效地需要测试分支成为生产分支。 （生产分支始终可用于维护版本，但在一个版本的部署和下一个版本的测试就绪之间不需要存在测试分支。）
使用代码促销的任何人都可以推荐实现从测试到生产推广分支的最佳方法吗？我认为这些是我的选择，但不知道他们是否有重大利弊：
一个。将测试分支完全合并到生产分支中，删除测试分支
湾删除生产分支，复制测试到生产，删除测试分支
C。删除生产分支，将测试分支重命名为生产
感谢您的任何建议！
答案 0 :(得分：2)
我一直认为分支是短暂的，我的所有版本实际上都在tags文件夹中。当某个版本需要修复时，标记将被复制到分支，完成工作并创建新标记。我很想知道是否有人有不同/更好的方法。
答案 1 :(得分：2)
第一个：选项b）和c）在subversion中是相同的，因为在subversion中重命名实际上是复制和删除。
那说你只有两个选择：
将测试分支完全合并到生产分支，删除测试分支
就颠覆而言，这是 clean 方式。您可以在svn log中看到哪些修订已合并到生产中，并且每个工作副本都保持不变。
但它有一个价格： 您必须手动执行合并并解决潜在的冲突（如果生成分支发生更改）。
但是，您通常可以通过少量开销来实现此目的
删除生产分支，将测试分支重命名为生产
这是 easy 方式，因为您只需执行一个非常小的可编写脚本的操作。
缺点：
您将使指向testbranch（已成为生产！）的所有workcopys无效。
合并跟踪要困难得多，因为您无法轻松查看旧的生产分支。生产分支的直接更改将丢失（不通知）！
另外请记住，您可能不希望testbranch中的所有提交都在生产中（如果一切正常，您为什么要测试？）。所以我强烈建议选项A
答案 2 :(得分：1)
您的生产分支机构应保持完整。按其发行号命名。 ProductName_Production_ {主要} {轻微} {}轻微。从测试迁移到生产时，您将创建一个具有最新版本号的新生产分支。如果您愿意，可以删除测试分支，但可以采用相同的方式处理。
作为构建过程的一部分，我通常会在部署下一个产品之前压缩当前的产品，以便在需要时可以恢复到最后一个稳定版本。只是一个假。
我通常不会以这种方式使用分支机构。我保持每个迭代标记，以便我拥有它们。我使用我的环境来推动代码从测试，到qa，到性能测试，再到生产。 Ziping每个包都有回滚功能。
答案 3 :(得分：0)
实际上我们在代码版本控制级别上没有区分主要工作分支和测试分支，但它对我来说很有意义。
我实际上会选择像
这样的方法测试完成后，将其复制到新的production1.1文件夹/分支。
答案 4 :(得分：0)
我为每个版本的任何分支或主干创建一个标记。
如果rc1可以接受，您只需将其再次标记为1.0_ga
答案 5 :(得分：0)
为什么要进行代码迁移？建立迁移代替！
4年多来，我们只使用了分支机构。我们采取了主干，并成为我们的第一个分支，称为RB-2013.07.0.x。这个分支是2013年7月的发布分支。我们锁定了卡车，因此没有人可以对其进行更改。所有更改均在RB-2013.07.0.x中进行。 7月发布完成后，我们锁定了RB-2013.07.0.x，因此无法对其进行更改。
与此同时，我们还从Trunk创建了9月发布的分支RB-2013.09.0.x。开发人员在7月发布的同时处理了9月份的发布。
在7月发布进入PROD之后，我们将RB-2013.07.0.x合并到RB-2013.09.0.x中。 我们再也没有回到主干。我们从未迁移任何东西。在超过4年的时间里，我们从未丢失过任何代码，而且，当您查看项目时，您确切知道分支的用途。
如果你有一个prod问题（热修复），你会采用当前的prod版本 - 比如RB-2013.07.0.x并创建一个分支RB-2013.07.1.x，让你改变，部署到prod，锁定分支，并将分支合并到上层分支 - RB-2013.09.0.x。这样，您将拥有最新的所有内容。
请记住，我们所做的每一个构建，都创建了一个TAG，并将其保存在TAGS目录中。
我们做的构建，我们将SVN的修订号添加到构建号的最后部分 构建将从开发，测试，到UAT / pre-prod，然后到prod。如果您想知道每个构建或分支中的代码，请进入SVN，并提取日志列表。