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

【问题标题】：how do I manage source code using SVN? branching, merging如何使用 SVN 管理源代码？分支，合并
【发布时间】：2010-12-02 08:42:46
【问题描述】：

我们是由 4 名开发人员/朋友组成的团队，分布在不同的地点。我们都已经开始在 ProjectX 上工作，并使用 Subversion 创建了分支 A、B、C 和 D。

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

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

我的问题是：

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

请建议我们应该使用什么工作流程？所以它在维护代码方面的痛苦最小。谢谢。

【问题讨论】：

标签： svn branch merge

【解决方案1】：

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

分支使您更难将您的代码更改与您的队友的代码更改集成。分支确实应该用于分支——创建软件的专门管理的“分支”。例如，如果您正在发布 1.0 版软件，最好从主干创建一个 1.0 分支（在开发之后但在发布之前），这样您就可以在不影响正在进行的情况下维护此版本在主干上进行开发（可能适用于 2.0 版）。

我建议抓住Pragmatic Version Control with Subversion。这是对 SCM 的一个非常扎实的概述，其中包含 Subversion 的细节。

【讨论】：

感谢您的想法。我一定会看看你提到的所有这些工具。

【解决方案2】：

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

【讨论】：

1：所以这意味着当我们认为我们完成时，主干 > 1 个分支（我们所有人都在处理它）.. 将此分支合并回主干。而且，如果需要应用补丁然后创建一个新分支并在新分支上工作，不要碰旧分支？关于 3，是的，我可以看到这个想法是多么“不正确”。感谢您的回答。
我同意你所说的大部分内容，除了最后一个。如果它们将提交可能破坏主构建的代码，则没有理由不使用分支。全部测试完后，就可以合并到主干了。这样他们的所有更改都将受到版本控制，但不会破坏主干。
Adam，我们正在为此使用另一个工具。它只是标记了所有适合包含在构建中的版本。

【解决方案3】：

还有一个发布 Eric Sink 的source control howto 链接的借口。

这是我所发现的对源代码管理的最佳介绍，并且无论您使用何种工具都具有相关性。

【讨论】：

【解决方案4】：

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

通过CMT（变更管理工具，如Bugzilla）向开发人员提供CR；
分析 CR。如果它有意义，它就会被接受，并且开发人员会为它创建一个分支。分支名称可能类似于：

projectName_crNumber_crCreationDate_developerId
工作完成后（测试、提交等），开发者应该锁定分支，所以没有人会改变它，标记 CR 为已解决（在 CR 处通知分支名称），然后等待 CM（配置管理器）将其合并到构建分支（以及其他开发分支）；
一定数量的 CR 合并到一个构建分支（build_xxx）后，应该测试这个集成版本。如果一切正常，则应将其合并到卡车上。
每次主干实现特定目标/里程碑（CR 集）时，都可以应用标签。

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

【讨论】：

【解决方案5】：

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

如果您预计您的代码在一段时间内至少存在两个版本，则分支很有用。例如，当您发布 2.0 版时，您想开始使用 2.1，但在可预见的未来必须支持 2.0。您可以将 2.1 作为一个全新的项目启动，但随后您将失去将修复从 2.0 移植到 2.1 的能力，反之亦然。所以你命名一个版本的主干并从中分支。

另一种情况是当你们中的一个人开始实施一个新模块或重新实施一个现有模块，并且知道这将需要一段时间（比您通常的提交周期更长）并且不能保证它不会影响其他人的那段时间的代码。然后你让他分支，开发他的东西，然后你想办法把它合并回来。再次，您有一个主干，您可以从中分支并合并回。

【讨论】：

为了避免分支更大的工作，您通常可以将新内容隐藏在启用它的标志后面。这仅在开发新功能的开发人员的工作区中设置为 true，所有其他人默认禁用它（但可以轻松地将其打开以进行临时测试）。
@starblue - 标志？你的意思是脚本中的某些内容？

【解决方案6】：

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

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

使用单个分支（如其他答案中所指出的主干）。当多个人必须处理相同的代码时，第二个签到的人将手动解决冲突。修复一个修订版中的冲突比尝试将多个修订版合并到另一个分支中更容易，而另一个分支在拆分后也推进了多个修订版。

【讨论】：

【解决方案7】：

如果您受限于 SVN，请继续阅读，如果不是，您听起来像是 DVCS 的主要候选人，例如 Mercurial、Git 或 Bazaar。

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

【讨论】：

老实说，我确实想到过要问我们是否继续使用 Git。