Question

我们是地理上多元化的软件开发人员团队，致力于ERP系统。我们使用SVN作为版本控制系统。在代码转移到生产系统之前，我们有4个环境。

我想知道在这种情况下使用SVN时分支，合并的最佳做法是什么。

目前我们遇到的问题是一个文件有4个更改。客户只希望在X（每年4个主要版本和4个次要版本）发布中进行2次更改。

我们面临的问题是：分支太多了。复杂的手动合并。失去轨道或变化覆盖别人的代码。

任何人都可以回答如何通过将SVN用作更好的工具来解决这个问题。

谢谢和问候，Kedar Hukeri。

Answer 1

如果将代码提供给主分支的过程可能比不同的工具更有帮助（除了具有良好差异/合并的源控制系统之外）。

这取决于您的流程，但通常是：

大型团队的良好实践是每个新的都有一个单独的分支特征/修复
开发人员在发布代码之前主线将拉最新的主要是他的分支和运行所有测试以确保一切正常
如果球队很大，你可能不得不这么做考虑一个发布经理 - 一个人简单地管理发布冻结主要分支和管理
更好，有发布分支机构和一个被允许合并的人新功能，开发人员提交注意新功能已准备就绪一个人合并了这些变化进入主要分支
冻结释放分支在发布和运行之前测试铁虫，不允许新的只有你修复bug的功能即将发布日期
取决于你提交的数量可以创建更小的版本更多测试，以建立里程碑和工作要知道的功能在每个点发布

最后，无论确切的过程是什么，主要的一点是开发人员了解程序并且有人强制执行。

Answer 2

首先要开始的地方之一是您可能已经咨询过的地方：Version Control With Subversion。另请查看list of books

引用的Subversion Dev Team

Answer 3

首先，请阅读：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Answer 4

我分享你的痛苦，与SVN有同样的问题，一旦你开始分支（你必须为了处理项目生命中的所有不同的情况），当一个项目的生命中处理所有不同的情况时，有一个很大的痛苦你开始合并，如果分支持续足够长的时间，合并就是一个完整的“项目”......

当然，更好的做法很有用，但如果该工具可以轻松实施其中的一些，那就太好了。

我被推荐Mercurial，我正在研究它取代SVN，它是按设计分发的，有（我被告知）更好的合并工具和更好/更容易的分支/存储库管理，所以你可能我也希望看一下。

Answer 5

您要求的是统一变更管理，这是Subversion实际上并不是为了做得好（IMO）。需要花费一些手动工作来管理变更。但假设你有适当的问题跟踪系统，这就是我工作过的很多地方：

main branch (trunk)  - new feature development here 
  |- release-1.0  - locked release branch 
  |--- release-sp1
  |--- release-patches - patch release fix stream (new fixes merged here)
  |------ release-sp1-issue# - this is where you make your bug fixes 
                               before merging them. 
                               This issue# is the bug-id in your tracking system.

修复错误并将其提交到修补程序版本后，删除旧的-issue＃branch。这可以防止分支失控，但可以让变更集变小。

可以通过使发布中继仅可写入集成商来实施维护者。通过apache：Subversion/Apache Permissions使用subversion，您可以创建一个组，集成商，并为您的项目设置以下权限

project 
  |- branches  (everyone: rw) 
      |- individual-fixes
  |- release-branches: (integrator: rw, everyone: ro) 
      |- release-1.0-fixes
      |- release-2.0-fixes
  |- trunk     (integrator: rw, everyone: ro) <- new dev goes here!!!!
  |- tags      (integrator: rw, everyone: ro) 
      |- release-1.0
      |- release-1.0-sp1 
      |- release-2.0

然后每个合并都很小，跟踪很好，只有一小部分人可以合并。但是，这会给您的合并团队带来瓶颈。我从未与一个大型的git / mercurial团队合作，看看它是如何工作的。

你也可以为功能修复实现类似的功能，但不要在你的主干上实现。

有关源代码管理的最佳实践是什么？

5 个答案: