我们目前正在使用TFS 2010来管理我们的源代码管理（MS商店，因此它是默认选择）。
对于我们的独立项目，我们没有任何问题。然而，我们有一个核心产品，我们在每个客户的基础上定制。许多客户端需要相当大的自定义，其他客户端只需要一些小的调整。
我们发现这是一场噩梦。我们基本上有一个包含核心产品的团队项目。如果客户不需要更改，他们只需要部署核心产品。如果他们要求更改，我们会将核心产品团队项目分支，并开始着手。
因此，需要更改的单个文件需要我们对整个产品进行分支。我们做错了吗？我有点想象我们会创建一个分支，其中包含每个客户所需的主要产品的差异。然后基本上客户端将获得核心+他们需要的任何更改。然后，如果我们添加到核心或更改它，他们就会自动获得。
我们不断地开发核心，所以我们似乎把我们的一生都花在了将变化融入所有分支项目中。我们目前有5个客户，但明年将有15-20个客户。然而，考虑到我们在5号的工作，这似乎完全无法控制。作为程序员，我们的生活似乎只是一次又一次的融合。现在，这在一定程度上是因为该产品是全新的，所以核心产品有很多流失。然而，我们将始终希望保持发展的核心。问题是，我们中没有人参与过这样的项目，所以我们不知道这是否是我们应该处理的方式
有人有什么想法吗？真的很感激任何建议，因为整个核心/分支/无休止的合并让我们很难过。有人向我的一位同事建议，git会帮助我们研究任何事情。
感谢
如果您的基础产品和分支产品具有相同文件的不同版本，无论您使用的是什么源代码管理产品，都将导致合并。有些（例如Git）使分支和合并变得相当容易，有些（如TFS）使其成为一项相当繁重的操作，但合并仍然需要完成。
一种更容易处理的策略是将代码分解为更易于管理的部分（脑海中浮现出SOLID），并将任何改编分解为特定于客户的类。如果有单独的文件用于客户调整，并且可以仅使用配置更改来注入类，那么根本没有理由为客户特定的更改进行分支。对客户特定类的更改所能做的最糟糕的事情就是破坏您为开发的客户。这将保留用于版本控制的分支（即dev/test/release分支），但不会获得版本控制和客户特定的分支。
根据代码的结构，您可能能够利用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将随着它们在Main分支中的变化而更新，d将只是功能分支中的更改。合并时，只需要合并和解决d中的更改。
虽然这将解决你的问题，但你需要明白这是相当复杂的。没有什么可以防止您在处理Feature1时意外地签入a、b或c的更改，这些更改将直接进入主分支。此外，通过不将自己与Main中的更改隔离开来，其他开发人员可以对a、b或c进行更改，这些更改不会导致Main中的构建中断，但会导致d中的构建断开（假设d依赖于a、b和c）。
这里有一个关于如何创建分部分支的好链接。
另一个注意事项是，您可以在任何级别为文件和文件夹创建部分分支。您不仅限于顶级文件夹。
git为TFS提供了两个可能对您有所帮助的优势。
首先，git中的分支创建简单快捷，不需要TFS似乎需要的那种规划和持续的概念负载。其次，也是最重要的一点，git允许您通过rebase而不是merge在分支之间移动更改；这确实有助于保持对账的干净和简单，并保持什么是分支开发，什么是主干。
此外，还有一个很好的工具git-tfs，它可以让您在使用git的同时在tfs中保留一个存储库。当您过渡到git时，或者如果您的公司要求您在TFS中保留一个"主"存储库，这可能会很好。
需要注意的是：虽然我认为您会发现git非常适合您的情况，但它并不是大部分git文档所涵盖的用例。很多git编写都侧重于分支和合并，而我认为在像您这样的情况下，优势在于分支和重新建立基础。它往往需要一段时间的使用才能真正"获得"git，并在偏离常规时知道该做什么（详细解释如何处理您的用例超出了StackOverflow的范围），因此您的团队可能需要一段时期才能将其放下。