如何使用SVN管理源代码？分支，合并

Question

我们是位于不同地点的4位开发人员/朋友的团队。我们都已经开始研究ProjectX并使用Subversion创建了分支A，B，C和D.

我们只掌握控制源代码的版本。有一天，我们中的一个人试图将分支A与B，C和D合并，而B和B试图与A，C和D合并。（他们甚至不知道如何合并它：D，只需右键单击＆gt;合并＆gt;合并一系列修订版）我们遇到了一些冲突，解决了它们。尝试再次合并，再次右击.....）再次冲突。

现在所有代码都搞砸了。我们有4个不同的代码副本（D缺少B的功能但有C等等）。所以我在SO上经历了很多线程，阅读了SVN书籍，尤其是this article (how to branch properly)在理解如何合并分支和主干方面提供了很多帮助。我想我对未来有了更好的了解。但是我如何摆脱目前的局面？

我的问题是：

• 我们4个人在同一个项目上工作，但通常在不同的位上工作，我们应该只有一个分支？然后创建4个工作副本，然后仅提交和更新。一旦我们准备合并trunk到分支，分支到trunk？根据{{​​3}}
中的建议
• 您能否建议任何工作流程，以便我们可以将我们的4个分支机构连接到主干，然后我可以进行导出以再次从头开始控制版本。
• 另外我认为如果再次使用4个分支，我们每个人每天/定期更新我们的分支并从主干（合并）获取更改并将本地更改合并回主干？ （而不是尝试mergin branch to branch :-D）

请建议我们应该使用哪些工作流程？这样它在维护代码方面的痛苦最小化。感谢。

Answer 1

我不会为每个开发人员创建一个分支。我推荐一个continuous integration进程，其中所有四个人都从一个“主干”中检出并经常合并更改 - 每天多次。理想情况下，您将拥有标准化的构建工具（例如Maven，Ant等）和构建调度程序（例如Hudson，Cruise，TeamCity等）。将这两个工具放在SCM工具（Subversion）之上，您可以让一个过程持续构建您检查到主干的所有更改，并在出现问题时通过电子邮件发送给所有开发人员。这可以防止您通过不良更改或合并破坏构建，同时允许您保持轻量级分支结构（即一个分支 - 主干）。

分支机构使您的代码更改与您的队友更改变得更加困难。分支应该真正用于分支 - 创建软件的特殊管理“分支”。例如，如果您要发布软件的1.0版本，那么从主干创建1.0分支（在开发之后但在发布之前）可能是一个好主意，因此您可以在不影响正在进行的情况下维护此版本在主干上开发（可能是2.0版）。

我建议抓住Pragmatic Version Control with Subversion。这是SCM的一个非常可靠的概述，具有Subversion的细节。

Answer 2

1. 您应该使用一个分支进行主要开发。这实际上不是一个分支，被称为“主干”。每个开发人员都应该对trunk进行更改。在代码发布或程序发生重大更改时，可能需要创建分支。然后，如果您对分支进行了一些更改（比如前一版本的补丁），并希望在主干中进行这些更改，则应将分支合并回主干。
2. 除了检查更改并手动合并到一个代码树之外，我不知道更好的方法。
3. 在你的情况下你不应该选择4个分支。这不是使用版本控制系统的正确方法。

Answer 3

另一个借口是发布链接到Eric Sink的source control howto。

这是我发现的源控制的最佳介绍，无论您使用哪种工具，它都是相关的。

Answer 4

最安全的策略是为每个 CR （变更请求/任务/错误/等）创建一个分支。 流程将是这样的：

1. 通过 CMT （变更管理工具，如Bugzilla）向开发人员提供CR;

2. 分析CR。如果它已经被接受并且开发人员为它创建了一个分支。分支名称可以是：

   projectName_crNumber_crCreationDate_developerId

3. 完成工作（测试，提交等）后，开发人员应该锁定分支，因此没有人会更改它，将CR标记为已解决（通知CR处的分支名称），然后等待 CM （配置管理器）将其合并到构建分支（以及其他开发分支）;

4. 将一定数量的CR合并到构建分支（build_xxx）后，应测试此集成版本。如果一切正常，那么它应该合并到卡车上。

5. 每次行李箱达到某个目标/里程碑（CR集）时，都可以应用标签。

省略了很多细节。这是一个由高质量标准的大型团队采用的工作流程。对于小团体来说，它可能不够灵活。但是，大多数此任务可以使用现有工具自动执行和安排。

Answer 5

通常，只有4个人在处理代码，你不需要4个分支。您可能根本不需要分支，只需将它们全部放入一个主干中即可。将您签出的本地工作副本视为“匿名本地分支”。

如果您预计代码在特定时间内至少存在两个版本，则分支很有用。例如，当您发布2.0版本，并且您想要开始使用2.1但是必须在可预见的未来支持2.0。您可以将2.1作为一个完整的新项目启动，但是您将失去将修复程序从2.0移植到2.1的能力，反之亦然。因此，您可以命名一个版本主干并从中进行分支。

另一种情况是，当你们中的一个人开始实施新模块或重新实现现有模块，并且知道它需要一段时间（比通常的提交周期更长）并且不能保证它不会影响其他人的那段时间的代码。然后你让他分支，发展他的东西，然后你弄清楚如何合并它。在这里，你有一个分支的主干并合并回来。

Answer 6

通常，如果您正在处理软件的不同部分，您会发现在同一个分支中工作最容易。如果您不经常处理相同的源文件或相互依赖的软件部分，那么当您提交时更新工作副本或损坏的源代码树时，您不会经常遇到冲突。

SVN中的分支（与分布式修订控制系统相对）更适用于可能破坏同事代码或需要大量工作的大而全面的更改（在这种情况下，您希望进行大量增量操作）可能无法编译的提交）或管理版本的事情。

使用单个分支（主干，如其他答案中所指出的）。当多个人必须处理相同的代码时，无论谁签到第二个都将手动修复冲突。修复一个修订版中的冲突很多比尝试将多个修改版本合并到另一个分支中更容易，因为它们分裂后也进行了多次修订。

Answer 7

如果您被限制为SVN，请继续阅读，如果没有，您听起来像是Mercurial，Git或Bazaar等DVCS的主要候选人。

对于SVN，根据我过去的经验，通常最好将主干保持在所有内容合并的位置（参见示例here）。每个人都应该合并回主干，然后从主干到你的分支合并。在SVN中从分支到分支的合并似乎是一个坏主意。