在多个开发人员之间使用Trunk / Branches和Tag结构

时间:2011-01-03 12:23:37

标签: svn tags branch trunk

当涉及到Trunk / Branches和Tags时,我最终会感到困惑。以下是我的询问:

我们有一个开发团队在一个项目上工作。开发人员通常分成小组,他们在同一个项目中处理各种模块。

目前,我们有一个简单的SVN系统(没有任何Trunk / Branches或Tags),每个人都在同一个本地服务器上工作并提交文件。但问题出现的时候,有几个开发人员在研究未来的模块(不应该立即上线)。在这种情况下,他们无法提交数据,因为如果他们这样做,他们的开发代码将被上传到实时服务器上,最终会弄乱一切。

所以,现在我正在寻找某种解决方案,这些开发人员可以单独工作但是使用相同的代码。像这样:

开发人员A正在开发新模块A. 开发人员B正在开发新模块B. 开发人员C正在开发模块C的Bug修复(已经上线但很少需要修复bug)

因此,开发人员A将在此计算机上拥有自己的副本,并将提交给Developer A的存储库。 (或分支)

同样的逻辑适用于开发人员B,但开发人员C将处理一个常见的稳定版本,该副本将位于标签中,一旦工作完成,它将被标记并推送到Trunk以在实时服务器上传。

开发人员A完成工作后,他会将所有文件推送到Trunk进行实时上传。 (这应该合并trunk中的一些常见文件)。同样的逻辑适用于开发人员B.

我不确定SVN是否适合这个解决方案。我甚至不知道是否有更简单的方法来实现我想要的东西。

欢迎提出任何建议。

由于 TTR

2 个答案:

答案 0 :(得分:3)

我的观点首先是,如果你的所有开发人员都在处理项目的各个部分,那么你可以取消分支机构。它可能需要一个小组织(例如适当的日志评论和版本控制),但这比分支和合并要麻烦得多。

好的,但是如果你想要分支机构,它们很容易。有几种方法,但基本上都涉及一个'主'版本,最终的代码最终。这可以是trunk,或者有些人喜欢在trunk上进行更改,然后合并代码以释放分支。 “主干是主人”是最容易理解的概念。

在svn中,制作一个分支很容易 - 它是一个便宜的副本,所以你唯一的问题就是用这些东西填满一个目录(我建议你一旦完成它就删除一个分支)。 SVN为这类工作提供了一种特殊的分支 - reintegration branch。这是特别的,因为SVN跟踪它发生了什么,它的设计是你从trunk创建一个分支,在它上面工作,偶尔用对trunk进行的更改来更新它,然后将你在该分支上的所有工作重新集成到一个trunk中最后一声巨响。然后你可以重新开始。听起来这可能是你想要的 - 通常,你不会为每个开发人员提供一个分支,你可以为每个工作包分配一个分支。

per-dev分支的问题在于,随着分支的寿命越来越长,它们所做的更改将更难以合并。如果开发人员没有定期将其他开发人员的工作合并到他们的分支中(因为他们不习惯),这一点尤其如此。

由于svn执行便宜的副本,我可能会建议为每个开发人员分支整个主干。我发现它更容易记住,而不是分支单个目录,你将始终能够更改共享或公共文件,而不必担心提交它们会破坏不同的分支。 (即如果你分支/ trunk / moduleA后来发现你需要更改/ trunk / include / common_file,那么当你分支一个子集时,公共文件将不会在你的分支中。所以只需在根处分支,因为它没有'额外花费你)

答案 1 :(得分:2)

在你的问题中,你刚刚表达了整个主干/标签/分支模型背后的基本原因 - 它是用于管理这种情况,这是开发商在一段时间后进入的正常情况。 / p>

计划的一件事是从无干线模型迁移到干线模型。

你说你没有任何主干,标签,分支等等所以我认为你的模型看起来像这样:

/
 filea.html
 fileb.html
 dira/
  filex

警告 - 不要尝试在自身下分支根目录

例如:

svn cp / /branchA

这会产生一个类似于:

的目录
/
 filea.html
 fileb.html
 dira/
  filex
 branchA/
  ...
 branchB/
  ...

取消选择根分支和子分支的一部分变得相当棘手。

保持清洁 - 首先将所有代码移入行李箱。这种结构性跳转需要每个人(以及所有部署系统)删除他们的工作区并从干净中获取所有内容:

svn cp / /trunk

现在你可以成为你的分支机构:

svn cp /trunk /branches/branchA

为您提供如下结构:

/
 trunk/
  filea.html
  fileb.html
  dira/
   filex
 branches/
  branchA/
   ...

分支完成后,开发人员可以检查它们并对其进行处理。您的部署系统可以指向trunk /而不是根文件夹并进行部署。

任何处理bug修复的开发人员都可以检查中继。当他们提交时,部署系统将像现在一样部署他们的更改。

当branchA完成后,开发人员可以将更改合并到主干中,就像gbjbaanb建议的那样。

快速抬头,祝你好运。