0

我知道这个理论,但是从项目的实际角度来看,svn 是如何使用的?比如说,我有一个网站,其中包含将要修改或添加的功能。在什么情况下会使用新的主干、分支和标签?

4

4 回答 4

2

不同的组织做非常不同的事情。Alex 上面给出的解决方案是一个常见的解决方案,但是它遇到了一个问题,即只有在您登陆分支后,您才会发现其他分支与您的分支有冲突。这导致人们不得不调试他们有一段时间没有看过的东西中的冲突。

我遇到的另一种常见方法是在主干中进行所有开发,并让开发人员将所有提交都设为小型、独立的提交。有多种方法可以添加功能并使其默认不可见,但在您的开发副本中打开。使用它们。这种方法需要开发人员的关注,但避免了管理较长寿命分支之间冲突的痛苦。

很多使用 Alex 解决方案的人会跳来跳去说:“这对小团队之外的任何事情都不起作用!” 对此我回应说,小团队没有任何问题,他们的生产力通常远远超过大团队所能做的任何事情。如果开发人员有纪律,这种策略可以扩展,例如谷歌使用它。如果您想查看使用该策略的实际项目,请查看http://llvm.org/

和一些建议。如果你想遵循 Alex 的策略,我强烈建议使用 git 而不是 svn。它比 svn 更好地处理分支。如果您想遵循我建议的策略,并且您的团队不是一个拥有您信任的人的小团队,您需要使用http://code.google.com/appengine/articles/rietveld.html之类的代码审查工具减少可能出现的明显问题。

于 2011-04-06T14:34:09.517 回答
2

看看这两篇文章:

http://www.snuffybear.com/ucm_branch.htm

http://www.vance.com/steve/perforce/Branching_Strategies.html

来自SnuffyBear的链接更多地说明了您似乎想要采用的策略,而另一篇文章则讨论了其他策略,例如逐个发布分支。每篇文章都概述了每种策略的优缺点。

于 2011-04-06T14:40:50.463 回答
1

我会说一个主干,其中进行了“稳定”的非常小的更改(可能是小错误修复),这不会破坏您的构建。

应为新功能/大更改建立分支。在分支机构运营期间,分支机构应及时更新您的主干更改。

完成新功能后,应将分支合并回主干,然后可以删除分支。

标签用于发布。例如 v1.2

于 2011-04-06T14:14:39.437 回答
1

我的拙见:合并分支是可怕的。在许多情况下,不同开发人员所做的更改是完全独立的,因此可以顺利合并。但是在任何繁忙的项目中,都会有变更冲突的时候。如果幸运的话,SVN 会识别冲突并在合并时为您提供错误。如果你不那么幸运,SVN 不会捕捉到它,但它无法编译。无论哪种方式,现在都必须有人弄清楚如何将这些更改放在一起。有时这很明显也很容易。但是我有很多次不得不召集进行更改的开发人员,以便我们弄清楚该怎么做。

如果你很不走运,SVN 和编译器都没有发现问题,冲突的更改会进入生产环境,并且程序的行为不正确。

从这个观察中,我得出两个结论: (a) 尽可能少地创建分支。或者更准确地说,制定策略以尽可能少地进行合并。并且 (b) 在代码仍在测试时合并代码。

有一段时间,我的公司有一个分支策略,说每个项目都有自己的分支,在该分支上进行测试,当我们准备部署到生产环境时,我们合并所有分支以包含在该版本中,编译和部署. 事实证明这是一个非常糟糕的主意。有人会在部署前一天尝试解决合并冲突,而合并的结果从未经过测试。许多微妙的错误悄悄进入生产环境。

我们暂时使用了这个策略:大多数开发都是在主干中完成的。当一个版本准备好移交给测试组时,我们会为它剥离一个分支。然后在主干中处理下一个版本。当前版本的任何错误修复都在分支中完成,并且此分支中的更改会定期合并回主干。有时需要同时进行 3 个版本的工作,即一个版本正在测试中,另一个版本接近准备好进行测试,现在我们需要开始下一个版本。在这种情况下,我们将拥有测试分支、当前版本的主干和下一个版本的“预”分支。当当前版本进入测试组时,我们会将“pre”分支合并到主干中,它成为当前版本。

我们最近开始尝试一种略有不同的策略。当一个版本处于测试阶段时,我们仍然会为它剥离一个单独的分支。但是任何来自测试的修复都是在主干中进行的,然后这些修复从主干合并到测试分支中。这意味着所有的开发都发生在主干中,而合并总是从主干到其他地方。这样做有两大好处:一是开发者总是在用trunk进行测试,所以我们对trunk中的代码是好的有更高的信心。测试组会针对发布分支进行测试,所以我们有信心发布分支是好的。也就是说,我们对这两个分支都将进行测试有一定的信心。当您在分支中进行更改然后合并回主干时。几乎无法保证有人会测试该合并的结果。二,主干总是有每个模块的完整“责备”历史。当您从分支合并回主干时。主干中的历史记录将分支的所有更改归因于进行合并的人,而不是真正进行更改的人,并且评论往往是无信息的“从分支 xyz 合并”。当您从主干合并到一个分支时,请确保该分支现在显示“错误”的人和一个无意义的评论,但主干具有良好的历史记录。有一个地方可以追寻历史,而不是试图追寻树枝。

于 2011-04-06T15:07:33.213 回答