当我应该为一些重大更改创建一个分支时，我却一直在主干上工作（Subversion，TortoiseSVN）。

Question

我开始进行了一系列的重大变更，涉及应用程序的许多不同领域，需要对数据库架构、对象和演示代码进行更改。我从1101版本开始。你可以考虑它是创建分支的完美案例，以便在测试和完成后合并到主干中。

但我没有创建新的分支，而是继续在主干上工作。

Trunk现在是rev.1116，我不得不对大约15个版本前的修订版本执行一些错误修复，这是当前生产发布的版本，然后发布修复了错误的“rev.1101+bugfixes”版本到生产中，而没有从revs 1102-1116中获取任何工作内容。

问题：我如何“恢复”Trunk并将所有最近的更改移动到一个Branch中？我是否应该从Trunk中创建一个Branch，并成为/Branches/MajorChangeSet，然后将Trunk回滚到rev.1101，将其视为现在的官方Trunk，并开始在那里进行错误修复的工作？

更新：我按照下面ChrisH的建议（如上图）进行了操作，现在我们状态很好。我们一直在更新"rev. 1102 production"，修复错误和小功能增强都很顺利，轻松合并到主干中，以确保这些变化也融入我们的新开发工作。谢谢大家！

分支与主干 | 分支/标签/主干？ | 何时创建分支？

- Mark A

Answer 1

每次开始制作发布候选版本时，我建议创建一个发布分支。Trunk用于处理不需要发布的工作（我们称之为下一个版本）。发布分支仅保留用于修复错误和必须发布的内容。始终将它们提交到trunk是一种很好的做法，然后再将它们精选合并到发布分支。尽量从trunk合并到其他分支，因为这样可以使事情更加简单。将“功能分支”重新集成到trunk是可以的，但应避免在发布分支中修复错误，然后将其合并回trunk。

发布后，发布分支将保留以修复其他错误并最终进行小版本发布。您仍然应首先在trunk中修复错误（没有必要在.next版本中发布它们），然后将它们合并到每个您仍在积极维护的发布分支中。

好消息是，您可以在事实上开始使用此方法。返回到当前版本构建的trunk修订版本，并从那里创建一个发布分支。TortoiseSVN在日志查看器中右键单击修订版本时有一个方便的菜单，可用于从特定修订版本创建标记和分支。

创建发布分支后，您需要检出它并开始合并要发布的错误修复。所有新的trunk工作都保持原样。如果trunk和发布分支差异很大，则可能需要直接在发布分支上进行修复，但尽量在trunk上进行修复，并在可以时合并到发布分支。

还有一件事。每次从发布分支发布版本时，您应该将其复制到标记中，并使用版本标签标记。稍后查找版本之间的更改或重建旧版本（如果需要）可能会很方便。我们甚至会从标记中进行完整构建，因为我们将SVN修订号嵌入产品版本中，以便如果客户报告错误，我们知道他们正在运行什么代码（因为SVN修订在存储库中是唯一的）。

希望这有所帮助，祝你好运。

- ChrisH

---

我很高兴它对你来说效果如此出色，我也很喜欢你更新问题并添加了图表。相比我发布的大段文字，图片更容易理解。 :) - ChrisH

Balsamiq模拟在此~ - Mark A

@MarkA：谢谢！我只是想知道你是如何绘制那些图表的 :P 非常有用的图表！ :) - Fil

Answer 2

一种方法是为每个主要版本创建一个分支，您可以在其中独立地应用错误修复，而不受主干上正在进行的任何工作的影响。

要回顾性地创建分支，请尝试：

svn copy http://svn/path/to/trunk@1101 \
         http://svn/path/to/branches/last_monday_release

@1101 是一个 peg 修订版 - 实际上我们的意思是“找出在修订版 1101 中所指的 trunk，然后将其复制以创建一个分支”。

（如果你感到勇敢，SVN 书中有一个可怕的解释关于 peg 修订版）

- SimonJ

---

我阅读了有关Peg修订的描述，感谢您的建议。我认为这就是我创建的分支吧？我使用TortoiseSVN的“显示日志”功能，并从r1101创建了一个新的分支。这比我预期的要容易得多！ - Mark A

是的，Tortoise几乎肯定在幕后处理这个问题。很高兴你解决了它，我也喜欢这些图表！ - SimonJ

Answer 3

嗯，无论从哪个角度看，这都有点混乱，但你也没有做错什么明显的事情。你只是继续在主干上开发 - 这是正确的 - 但现在你需要回到以前的版本并添加一些更改，然后重新发布。

问题似乎是你有一系列修复错误和新功能的版本，而你只是试图从某个时间点开始处理错误，并忽略其他所有内容。如果修复错误的版本是离散的（至少用于识别目的），那么这将会更容易，但通常它们往往伴随着其他更改。

两个选择：

1. 获取您发布的最后一个版本的分支，然后手动移动您的错误修复。
2. 获取最后一个具有错误修复的版本的分支，然后删除新功能。

根据新功能和错误修复之间的平衡，其中一个选项可能比另一个更容易。无论哪种方式，您都希望最终得到一个专门用于此版本的分支。

- Troy Hunt

Answer 4

解决这个问题的一种方法是：

• 从主干的HEAD创建一个工作分支
• 删除主干
• 重新创建主干，使用您意外更改之前的主干版本

这样，您就不会在主干的日志/责备中看到意外提交和还原。但是请注意，在更新工作副本时要小心 - 我不确定 svn update 如何处理存储库位置的删除和重新创建。

- paperjam

---

哎呀。我想在这些操作期间会丢失很多日志历史记录？ - Mark A

@Mark，您不会丢失任何日志历史记录。 svn log trunk 只会显示额外的复制操作。而您可以将您的意外更改变成一个分支，同样不会丢失任何历史记录。 - paperjam