1

当谈到主干/分支和标签时，我最终会感到困惑。以下是我的查询：

我们有一个开发人员团队致力于一个项目。开发人员通常分成几组，他们在同一个项目的不同模块上工作。

目前，我们有一个简单的 SVN 系统（没有任何主干/分支或标签），每个人都在同一本地服务器上工作并提交文件。但问题开始于，一些开发人员正在开发未来的模块（这些模块不应该立即上线）。在这种情况下，他们无法提交数据，因为如果他们提交了，他们的开发代码将被上传到实时服务器上，最终会搞砸一切。

所以，现在我正在寻找某种解决方案，这些开发人员可以在相同的代码上单独工作。像这样的东西：

开发人员 A 正在开发新模块 A 开发人员 B 正在开发新模块 B 开发人员 C 正在修复模块 C 的错误（已经上线，但需要修复的错误很少）

因此，开发人员 A 将在这台机器上拥有自己的副本，并将提交到开发人员 A 的存储库。（或分支）

相同的逻辑适用于开发人员 B，但开发人员 C 将处理一个通用的稳定副本，该副本将位于标签中的某个位置，一旦工作完成，它将被标记并推送到主干，以便在实时服务器上上传。

开发人员 A 完成工作后，他会将所有文件推送到 Trunk 进行实时上传。（这也应该合并主干中的一些常见文件）。相同的逻辑适用于开发人员 B。

我不确定 SVN 是否是正确的解决方案。我什至不知道是否有任何更简单的方法来实现我想要的。

欢迎任何形式的建议。

谢谢 TTR

4

2 回答 2

3

my opinion firstly is that if all your devs are working on separate pieces of the project, then you can do away with branches. It may take a little organisation (eg proper log comments and versioning) but that can be a lot less hassle than branching and merging.

Ok, but if you do want branches, they're easy. There are several approaches to this, but basically all involve a 'master' version where the final code ends up. this can be trunk, or some people prefer to make changes on trunk and then merge the code to release branches. The 'trunk is master' is the easiest concept to grasp though.

In svn, making a branch is easy - its a cheap copy so your only problem is filling up a directory with the things (I recommend deleting a branch once you're done with it). SVN gives you a special kind of branch for this type of work too - the reintegration branch. It is special as SVN tracks what happens to it, its designed that you create a branch from trunk, work on it, occasionally updating it with changes that have been made to trunk, and then reintegrate all your work on that branch into trunk in one final bang. Then you can start all over again. It sounds like this could be what you want - typically though, you wouldn't have a branch per developer, you'd have a branch for each package of work.

The trouble with per-dev branches is that as a branch lives longer and longer, the changes they make will be harder and harder to merge back. This is especially true if the developers do not merge the other dev's work into their branches regularly (as they are wont to do).

As svn does cheap copies, I would probably recommend branching the entire trunk for each developer. I find that its easier to remember that instead of branching individual directories, and you'll always be able to change shared or common files without having to worry if committing them will break a different branch. (ie if you branch /trunk/moduleA and later find you need to change /trunk/include/common_file then the common file will not be in your branch as you branched a sub-set. So just branch at the root as that doesn't cost you any extra)

于 2011-01-03T13:01:48.550 回答
2

在您的问题中，您刚刚表达了整个主干/标签/分支模型背后的基本原因 - 它是为了管理这种情况，这是开发商店在短时间内进入的正常情况。

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

你说你没有任何树干、标签、分支等。所以我假设你的模型看起来像这样：

/
 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/ 而不是根文件夹并进行部署。

任何致力于错误修复的开发人员都可以检查主干。当他们提交时，部署系统将像现在一样部署他们的更改。

当 branchA 完成后，开发人员可以按照 gbjbaanb 的建议将更改合并到主干中。

只是快速抬头，祝你好运。

于 2011-01-03T15:43:45.080 回答