我刚刚将一个由7名开发人员组成的团队从VSS迁移到了TFS。我将他们的所有代码迁移到DEV文件夹中，然后我将其分支到QA文件夹（我将其分支到PROD文件夹中）。开发人员通常不使用相同的文件，但有一些共享的实用程序类。所有代码都适用于大型ASP.NET网站。当开发人员准备从DEV合并到QA时，他们只想合并他们的更改。例如，假设Developer1过去3个月一直致力于项目，他已准备好将所有代码合并到QA中。但是，Developer2在过去的两个月中一直致力于另一个项目，但尚未准备好合并。 Developer1和Developer2的更改不以任何方式相互依赖，但它们不会分成不同的文件夹结构，并且每个都经常进行最新的更新。似乎没有办法让developer1只合并他的更改而不合并所有developer2的更改。目前，developer1正在进行Pending Changes窗口和所有Developer2的更改的“撤消待定更改”，但这非常耗时。他们可以单独合并每个文件，但这也很耗时。有没有更简单的方法？如果我再听一个人解释在VSS中工作有多容易，我将会有一个冠状动脉。
答案 0 :(得分：0)
听起来最好的策略（未来）是分支项目。如果Dev1和Dev2正在处理根本不同的事情，那么每个人都应该拥有自己的代码分支。
请记住，TFS中的所有内容都存储为增量和指针，因此您不会通过执行此操作来大幅增加存储库的大小。在文件更改之前，新分支只是指向原始文件的指针，然后在签入文件时，只存储增量。
在您目前的情况下，您正在进行所谓的“樱桃挑选”合并。这不是一件有趣的事情（正如你所发现的那样），并且容易出现PEBKAC错误。出于这个原因，强烈建议不要采用樱桃挑选合并。但是，如果你确实需要进行cherry-pick合并，你可以通过改变set（而不是最新的）合并来控制一些。
为此，请确定Dev1已检入Dev分支的变更集，然后将这些变更集合并到主线分支中。您需要按照从最旧到最新的顺序执行此操作，以确保获取所有文件。您最好的选择是，如果要执行此操作，可以编写实用程序来执行此操作，也可以向下移动到TF.EXE命令行，这样您就可以将合并批处理。
请记住在干净的工作区中进行合并，并且可以在签入之前批量处理所有合并。
您在这里学到的关键教训是，您的分支策略/方法是SCM最重要的事情之一（一般而言）。我们在一年半前从StarTeam迁移到TFS，当我们这样做时，我们花了大约4个月的时间来修改我们的分支方法，直到我们找到适合我们的环境和开发过程的东西。
答案 1 :(得分：0)
是否有理由将它们分支所有更改而不仅仅是自己的更改集？
合并对话专门询问您是否要分支“所有更改到特定版本”或“仅特定更改集”。如果您选择后者，那么您可以挑选您的更改，而不需要采用每个人的代码。假设每个开发人员正在处理一组非重叠的文件，这不会导致您出现问题。