我们目前正在使用TFS 2010管理我们的源代码管理（MS商店，因此它是默认选择）。
我们的独立项目没有任何问题。但是，我们有一个核心产品，我们在每个客户的基础上定制。许多客户需要非常重要的自定义，其他客户只需要进行一些小的调整。
我们发现这是一场噩梦。我们基本上有一个包含核心产品的团队项目。如果客户端不需要更改，则只需部署核心产品即可。如果他们要求进行更改，我们会分支核心产品团队项目并开始研究。
因此，需要更改的单个文件需要我们分支整个产品。我们这样做错了吗？我有点想象我们会创建一个包含与每个客户需要的主要产品不同的分支。然后基本上客户端将获得核心+他们需要的任何更改。然后，如果我们添加到核心或更改它，那么他们就会自动获得它。
我们不断开发核心，所以我们似乎把生活融入所有分支项目。我们目前有5个客户，但明年将有15-20个客户正在筹备中。然而，考虑到我们正在进行的工作，这似乎完全无法管理。我们作为程序员的生活似乎只是在合并后合并。现在这部分是因为产品很新，所以核心流失很多。但是，我们总是希望继续开发核心。问题是我们没有人曾经在这样的项目上工作过，所以我们不知道这是不是我们应该如何处理它。
有没有人有任何想法？真的很感激任何建议，因为整个核心/分支/无尽的合并让我们感到难过。有人向我的一位同事建议，git可以帮助我们查看任何内容。
由于
答案 0 :(得分：5)
如果您的基础产品和您的分支产品具有相同文件的不同版本，无论您正在使用哪种源代码管理产品，您最终都会进行合并。一些（例如Git）使分支和合并相当容易，一些（如TFS）使它成为一个相当繁重的操作，但合并仍然必须完成。
一种使其更容易处理的策略是将代码分解为更易于管理的部分（SOLID comes to mind），并将任何适应性分解为客户特定的类。如果客户调整有单独的文件，并且可以仅使用配置更改来注入类，则根本不需要为客户特定的更改进行分支。客户特定类的最大变化是打破您正在开发的客户。这将保留版本控制的分支（即开发/测试/发布分支），但您不会获得版本控制和客户特定分支。
答案 1 :(得分：3)
根据代码的结构，您可以利用TFS中的部分分支。假设您的主分支名为“Main”，它有四个子文件夹：“a”，“b”，“c”，“d”。如果你知道你只想改变“d”那么你只会将“d”分支到你的新分支，这可以称为“Feature1”。
所以，在TFS中你会有这个文件夹结构：
Main/
a/
b/
c/
d/
Feature1/
d/
现在，正确使用此部分分支的技巧是在处理Feature1时设置正确的工作空间映射。你想要的是一个/ 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）。 / p>
这是关于如何创建部分分支的好link。
另外请注意，您可以在任何级别为文件和文件夹创建部分分支。您不仅限于顶级文件夹。
答案 2 :(得分：2)
git为TFS提供了两个可能对您有帮助的优势。
首先，在git分支中创建简单快捷，并且不要求TFS似乎需要的那种规划和持续的概念负载。其次，最重要的是，git允许您使用rebase而不是merge来在您的分支中移动更改;这可以真正有助于保持对帐清洁和简单，并保持非常独特的是什么是分支发展和什么是主干。
此外，有一个很好的工具git-tfs，它允许你使用git，同时仍然在TFS中保存一个存储库。当您转换到git时，或者如果您的公司要求您保留一个＆＃34; master＆＃34;未来TFS中的存储库。
有一点需要注意：虽然我认为你会发现git非常适合你的情况，但它并不是大多数git文档所涵盖的用例。很多git写作专注于分支和合并，而我认为像你这样的案例的优势在于分支和重新基础。它往往需要一段时间才能真正实现＆＃34;得到＆＃34; git并且知道在偏离常规路径时做正确的事情（并且详细解释如何详细地使用用例 - 超出StackOverflow的范围），因此可能需要一段时间才能让团队失败。< / p>