版本控制系统 - ＆gt;分支问题

Question

我正在开展下一个任务，突然明白我需要与我的主管讨论一些细节才能继续。我会在几天内讨论这个问题。在那之前，我需要处理另一项任务。

正确的做法是什么？

我看到两个选项：

1）将头部修订从存储库复制到新分支并在那里启动另一个任务。完成后 - 将其合并到主干。或者我可能需要先从主干到分支合并，然后合并回主干？

2）从工作副本复制到新分支。将主干恢复到最后一个版本（在我开始我需要讨论的任务之前），切换到主干并处理另一个任务，然后在分支中完成当前任务并合并。

请详细解释正确的方法，因为我不是经验丰富的VCS用户。提前谢谢。

Answer 1

您面临的问题是您在中继上启动了更改，但又希望将其提交到其他地方。大多数版本控制系统没有内置的行为，这是不幸的。在SVN中，你最好的选择是：

1. 从主干
创建新分支
2. 执行SVN切换以将当前工作副本切换到该分支
3. 您现在应该进行本地更改并能够在新分支上提交
4. 将它们提交到分支后，再次切换回trunk
5. 处理主干上的新功能
6. 在与主管讨论细节之后，将他们从分支机构合并到主干

希望有所帮助

Answer 2

真的两种选择都适合你，而且两种选择都不正确;决定最简单行动的因素是合并变更所需的难度。通常在svn中，如果可能的话，你想避免合并。

通常这种决定取决于你的团队文化;如果您的同事通常不希望在主干中进行未完成/未批准的更改，那么将更改移动到分支然后在主管批准您的代码后合并是有意义的。当然，如果你单独工作，那一切都取决于你。

根据您的具体情况，您确实有第三个选项可能有效，也可能无效，这只是同时处理主干中的两个任务，并单独提交各个更改。

Answer 3

我会做第一个选择，因为我可以保持我的行李箱干净（一直工作）。由于您正在谈论的功能仍需要您的老板确认。如果该功能最终被丢弃，您的主干仍然不会受到影响，并且您的团队中的其他成员不会与该更改混淆。

Answer 4

我们根据发布而不是任务进行分支。所以现在我们准备在几周内发布的所有内容都在分支机构5.1.1中。这些更改在发布到生产时合并回主干。