logo标签列表

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

svnbranchmerge
3
我们是一支由4名位于不同地点的开发者/朋友组成的团队。我们都开始着手开发一个名为ProjectX的项目，并使用Subversion创建了A、B、C和D四个分支。
我们只有基本的源代码版本控制知识。前几天，我们中的一位尝试将A分支与B、C和D合并，B则试图将其与A、C和D合并（他们甚至不知道如何合并：D，只需右键单击>合并>合并一系列修订）。我们遇到了一些冲突，解决了它们。尝试再次合并，再次右键单击......又出现了冲突。
现在所有的代码都乱了。我们有4个不同的代码副本（D缺少B的功能，但具有C的功能等等）。因此，我在这里阅读了很多线程，阅读了SVN书籍，特别是这篇文章（如何正确分支）对理解如何合并分支和主干帮助很大。我想我已经对未来有了更好的理解。但是我该如何摆脱当前的状况呢？
我的问题是：
  • 我们四个人在同一个项目上工作，但通常会分别处理不同的部分，我们应该只有一个分支吗？然后创建4个副本，只提交和更新这些副本。一旦准备好，将主干合并到分支，再将分支合并到主干，如上面的文章中建议的那样。
  • 您能否建议任何工作流程，以便我们可以将4个分支合并到主干，然后我可以导出并从头开始进行版本控制。
  • 此外，我认为如果再次使用4个分支，每个人是否应该每天/定期更新自己的分支，并从主干获取更改（合并），然后将本地更改合并回主干？（而不是尝试将分支合并到分支：-D）

请建议我们应该使用什么工作流程，以便在维护代码时最小化痛苦。谢谢。

7个回答
8
我不会为每个开发者创建一个分支。我建议使用持续集成流程，所有四个人都从单个“主干”检出并频繁合并更改——每天多次。理想情况下，您将拥有标准化的构建工具（例如Maven、Ant等）和构建调度程序（例如Hudson、Cruise、TeamCity等）。通过在SCM工具（Subversion）之上使用这两个工具，您可以持续构建您在主干中检入的所有更改，并在出现问题时向所有开发人员发送电子邮件。这可以保护您免受坏的更改或合并导致构建失败的影响，同时允许您保持轻量级的分支结构（即一个分支——主干）。
分支使代码更难与队友的代码更改集成。分支应该真正用于创建特别管理的软件“分支”。例如，如果您要发布软件版本1.0，那么在主干（开发但在发布之前）上创建一个1.0分支可能是个好主意，这样您就有了一个地方来维护此版本，而不会影响主干上正在进行的开发（也许是2.0版）。
我建议获取《Subversion实用版本控制》。它是关于SCM的相当全面的概述，并且具有针对Subversion的具体细节。
谢谢你的想法。我一定会查看你提到的所有工具。 - TigerTiger
2
最安全的策略是为每个CR（变更请求/任务/错误等）创建一个分支。流程将如下所示：
  1. 通过CMT（Change Management Tool，如Bugzilla），开发人员接收到CR;
  2. 分析CR。如果有意义，就接受并为其创建分支。分支名称可能类似于：

    3. projectName_crNumber_crCreationDate_developerId

  3. 工作完成后（测试、提交等），开发人员应该锁定分支，以防止其他人更改它，标记CR为已解决（在CR中通知分支名称），并等待配置管理器（CM）将其与其他开发分支合并到构建分支中;
  4. 将一定数量的CR合并到构建分支（build_xxx）后，应对此集成版本进行测试。如果一切正常，应将其合并到Trunk。
  5. 每当Trunk达到某个目标/里程碑（一组CR）时，都可以应用标签。
省略了很多细节。这是大型团队采用的流程，具有高质量标准。它可能不够灵活，无法适应小团队。但是，现有工具可以自动化和调度大部分任务。
2
  1. 您应该使用一个分支进行主要开发。这实际上不是一个分支，而是称为“trunk”。每个开发人员都应该向trunk提交更改。当您进行代码发布或程序的重大更改时，可能需要创建一个分支。然后，如果您对分支进行了一些更改（比如说先前版本的补丁），并且希望在主干中也有这些更改，那么您应该将分支合并回trunk。
  2. 我不知道除了手动合并到一个代码树之外还有什么更好的方法。
  3. 在您的情况下，您不应该使用4个分支。这不是正确使用版本控制系统的方式。
这意味着主干 > 1个分支（我们所有人都在上面工作），当我们认为完成时，将该分支合并回主干。如果需要应用补丁，则创建一个新分支，并在新分支上工作，不要触碰旧分支？关于问题3，我可以看到这个想法是多么“不正确”。感谢您的回答。 - TigerTiger
1
我同意你说的大部分内容，除了最后一点。如果他们提交可能会破坏主干构建的代码，那么没有理由不使用分支。在所有测试完成之后，再将其合并到主干上。这样，他们所有的更改都将受到版本控制，但不会破坏主干。 - Adam W
Adam，我们正在使用另一个工具来实现这个目的。它会标记所有适合包含在构建中的版本。 - grigy
2
另一个发布Eric Sink的源代码控制指南链接的借口。
这是我发现的迄今为止最好的源代码控制入门指南，无论你使用哪种工具都适用。
1

通常情况下，只有4个人在编写代码时，您不需要4个分支。您可能根本不需要分支，只需将所有内容放入一个主干中并在其上工作即可。将您签出的本地工作副本视为“匿名本地分支”。

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

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

为了避免即使在更大的工作中也要进行分支，您通常可以将新内容隐藏在启用它的标志后面。这仅在正在开发新功能的开发人员的工作区中设置为true，其他所有人默认情况下都已禁用它（但可以轻松地打开它进行临时测试）。 - starblue
@starblue - 旗帜？你是指脚本中的某些东西吗？ - TigerTiger
0

通常情况下，如果你们都在开发软件的不同部分，最好从同一个分支开始工作。如果你们不经常在同一源文件或相互依赖的软件部分上工作，那么在更新工作副本时，你不会经常遇到冲突或提交时出现错误的源代码树。

在 SVN 中（与分布式版本控制系统相比），分支更适用于大规模、彻底的更改，这些更改很可能会破坏你同事的代码或需要大量工作（在这种情况下，你需要进行许多增量提交，这些提交可能无法编译），或者用于管理发布等任务。

选择单个分支（如其他答案中指出的主干）。当多人必须在同一代码上工作时，第二个检入的人将手动解决冲突。在一个修订版本中解决冲突比尝试将几个修订版本的更改合并到另一个分支中要容易得多，而该分支也已经自它们分离以来进行了几个修订版本。

0
如果你被限制在使用 SVN，那么请继续阅读。如果不是，那么你似乎是 Mercurial、Git 或 Bazaar 这类分布式版本控制系统的优秀候选人。
对于 SVN，根据我的经验，通常最好将主干保持在一起，所有东西都合并到这里（可以看看这里的示例）。每个人都应该将代码合并回主干，然后再从主干合并到自己的分支。在 SVN 中，从一个分支合并到另一个分支似乎不是一个好主意。
说实话，我也想问一下，如果我们转向Git会怎样。 - TigerTiger
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接