2

我们目前正在使用 TFS 2010 来管理我们的源代码控制（MS 商店，所以它是默认选择）。

对于我们的独立项目，我们没有任何问题。然而，我们有一个核心产品，我们根据每个客户定制。许多客户需要相当大的定制，而其他客户只需要一些小的调整。

我们发现这是一场噩梦。我们基本上有一个包含核心产品的团队项目。如果客户不需要更改，他们只需部署核心产品。如果他们要求更改，我们会分支核心产品团队项目并开始着手处理。

因此，需要更改的单个文件需要我们对整个产品进行分支。我们做错了吗？我有点想像我们会创建一个分支，其中包含每个客户需要的主要产品的差异。然后基本上客户将获得核心+他们需要的任何更改。然后，如果我们添加到核心或更改它，那么他们就会自动得到它。

我们一直在开发核心，因此我们似乎一生都在将更改合并到所有分支项目中。我们目前有 5 个客户，但明年将有 15-20 个客户。然而，考虑到我们在 5 上所做的工作，这似乎完全无法管理。我们作为程序员的生活似乎只是一次又一次地合并。现在这部分是因为产品很新，所以核心有很多流失。但是，我们将始终希望继续开发核心。问题是我们都没有做过这样的项目，所以我们只是不知道我们应该如何处理它。

有人有什么想法吗？非常感谢任何建议，因为整个核心/分支/无尽的合并让我们感到难过。有人向我的一位同事建议，git 可以帮助我们查看任何内容。

谢谢

4

3 回答 3

5

如果您的基础产品和分支产品具有相同文件的不同版本，那么无论您使用什么源代码控制产品，最终都会合并。有些（例如 Git）使分支和合并相当容易，有些（例如 TFS）使它成为一个非常繁重的操作，但仍然必须完成合并。

一种使它更容易处理的策略是将代码分解成更易于管理的部分（想到 SOLID）并将任何适应分解为客户特定的类。如果有用于客户调整的单独文件，并且可以仅使用配置更改来注入类，那么根本就没有那么多理由为客户特定的更改进行分支。对特定于客户的类所做的最糟糕的更改就是破坏您正在为其开发的客户。这将继续为版本控制分支（即开发/测试/发布分支​​），但您不会获得版本控制和客户特定的分支。

于 2012-08-26T13:16:38.073 回答
3

根据您的代码结构，您可以利用 TFS 中的部分分支。假设您的主分支名为“Main”，它有四个子文件夹：“a”、“b”、“c”、“d”。如果您知道您只会更改“d”，那么您只会将“d”分支到您的新分支，该分支可以称为“Feature1”。

因此，在 TFS 中，您将拥有以下文件夹结构：

Main/
    a/
    b/
    c/
    d/

Feature1/
    d/

现在，正确使用此部分分支的技巧是在处理 Feature1 时设置正确的工作区映射。你想要的是让 a/ b/ 和 c/ 来自 Main 和 d/ 来自 Feature1。您可以使用以下映射：

(active) C:/dev/Feature1 -> $/TeamProject/Main
(cloaked) $/TeamProject/Main/d
(active) C:/dev/Feature1/d -> $/TeamProject/Feature1/d

因此，现在，在您的工作区中，a、b 和 c 将随着主分支中的更改而更新，而 d 将只是功能分支中的更改。合并时，只需要合并和解析 d 中的更改。

虽然这将解决您的问题，但您确实需要了解它相当复杂。没有什么可以阻止您在处理 Feature1 时意外检查 a、b 或 c 的更改，这些更改将直接进入主分支。此外，通过不将自己与 Main 中的更改隔离开来，其他开发人员可以对 a、b 或 c 进行更改，这些更改不会导致 Main 中的构建中断，但会导致 d 中的构建中断（假设 d 依赖于 a、b 或 c）。

这是一个关于如何创建部分分支的好链接。

另外一点，您可以为任何级别的文件和文件夹创建部分分支。您不仅限于顶级文件夹。

于 2012-08-27T10:32:40.647 回答
2

git 为 TFS 提供了两个可能对您有所帮助的优势。

首先，在 git 中，分支创建起来既简单又快速，并且不需要 TFS 似乎需要的那种计划和持续的概念负载。其次，也是最重要的，git 允许您通过变基而不是合并来跨分支移动更改；这确实有助于保持对账的清洁和简单，并非常清楚什么是分支开发和什么是主干。

此外，还有一个不错的工具 git-tfs，它可以让您在使用 git 的同时仍将存储库保留在 TFS 中。当您正在过渡到 git 时，或者如果您的公司要求您在 TFS 中保留一个“主”存储库，这可能会很棒。

一个警告：虽然我认为您会发现 git 非常适合您的情况，但它并不是大部分 git 文档所涵盖的用例。很多 git 写作都集中在分支和合并上，而我认为像你这样的案例的优势是分支和重新定位。在您真正“获得” git 并知道在偏离常规路径时该做正确的事情之前往往需要一段时间的使用（并且详细解释如何执行您的用例超出了 StackOverflow 的范围），因此可能需要在你的团队搞定它之前的一段时间。

于 2012-08-26T13:19:28.420 回答