如何使用SVN管理源代码?分支、合并

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

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

我建议抓取 Pragmatic Version Control with Subversion . 这是一个非常可靠的SCM概述,包含Subversion的详细信息。

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

还有另一个借口去贴Eric Sink的链接 source control howto .

这无疑是我所发现的最好的源代码管理介绍,无论您使用何种工具,它都是相关的。

最安全的策略是为每个分支创建一个分支 流程如下所示:

1. CR通过 CMT (变更管理工具,如Bugzilla);

2. 对CR进行了分析。如果它有意义,它就会被接受,开发者会为它创建一个分支。分支名称可能类似于:

   项目名称\u crNumber\u crCreationDate\u developerId

3. 在工作完成(测试、提交等)后,开发人员应锁定分支机构,这样就不会有人更改它,将CR标记为已解决(通知CR处的分支机构名称),然后等待解决 厘米

4. 在将一定数量的CR合并到一个构建分支(build_xxx)中后,应测试此集成版本。如果一切正常,则应将其合并到卡车上。

5. 每次主干达到某个目标/里程碑(一组CR)时,都可以应用标签。

通常,只有4个人在编写代码,你不需要4个分支。您可能根本不需要分支,只需将所有分支放在一个主干中,然后再进行操作即可。将您签出的本地工作副本视为您的“匿名本地分支”。

如果您预期您的代码在一段时间内至少存在两个版本,则分支非常有用。例如,当您发布2.0版时,您希望开始使用2.1版,但在可预见的未来必须支持2.0版。您可以将2.1作为一个全新的项目启动,但这样您就失去了将补丁从2.0移植到2.1的能力,反之亦然。因此,您可以从中命名一个版本主干和分支。

另一种情况是,当你们中的一个人开始实现一个新模块或重新实现一个现有模块,并且知道这将需要一段时间(比通常的提交周期更长),并且不能保证在这段时间内不会影响其他人的代码。然后你让他分支,发展他的东西,然后你想办法把它合并回来。在这里,你有一个主干你分支和合并回。

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

用一根树枝(树干,如其他答案中所指出的)。当多人必须处理同一代码时,第二个签入的人将手动修复冲突。在一次修订中修复冲突是非常困难的 很 比尝试将更改的多个修订合并到另一个分支更容易,因为该分支自拆分后也进行了多个修订。

如果你仅限于SVN,请继续阅读,否则,你听起来像是SVN的主要候选人 DVCS 比如Mercurial、Git或Bazaar。

here ).每个人都应该合并回主干,然后从主干合并到分支。在SVN中从一个分支合并到另一个分支似乎是个坏主意。