用于用于VSS的用户的TFS合并

我刚刚将一个由7名开发人员组成的团队从VSS迁移到TFS。我将他们的所有代码迁移到一个DEV文件夹中，然后将其分支到一个QA文件夹中，并将其分支到PROD文件夹中。开发人员通常不处理相同的文件，但是有一些共享的实用程序类。所有代码都适用于大型ASP.NET网站。当开发人员准备从DEV合并到QA时，他们只想合并他们的更改。例如，假设Developer1在过去3个月里一直在做一个项目，他准备将所有代码合并到QA中。然而，Developer2在过去的两个月里一直在处理一个不同的项目，这个项目还没有准备好合并。Developer1和Developer2的更改在任何方面都不是相互依赖的，但是它们并没有被划分到不同的文件夹结构中，并且它们都定期进行最新的获取。似乎没有办法让developer1只合并他的更改而不合并developer2的所有更改。目前，developer1正在通过“挂起的更改”窗口，并为Developer2的所有更改“撤消挂起的更改”，但这很耗时。他们可以单独合并每个文件，但这也很耗时。有没有更简单的方法？如果我再听到一个人解释在VSS中工作是多么容易，我就会有冠状动脉病变。

听起来最好的策略是在项目上分支。如果Dev1和Dev2处理的是根本不同的事情，那么它们都应该有自己的代码分支

请记住，TFS中的所有内容都存储为增量和指针，因此这样做不会大幅增加存储库的大小。在文件更改之前，新分支只是指向原始文件的指针，然后在签入文件时，只存储增量

在你目前的情况下，你正在进行所谓的“樱桃-精选”合并。当你发现这不是一件有趣的事情时，它很容易出错。出于这个原因，强烈反对“樱桃-精选”合并。然而，如果您确实需要进行cherry-pick合并，您可以通过按变更集而不是最新的变更集进行合并来进行一些控制

为此，确定Dev1已签入到Dev分支中的变更集，然后将这些变更集合并到主线分支中。您需要按照从最旧到最新的顺序进行操作，以确保获得所有文件。如果要执行此操作，最好的方法是编写一个实用程序来执行此操作，或者向下移动到TF.EXE命令行，以便将合并批处理在一起

请记住在干净的工作区中进行合并，您可以在签入之前对所有合并进行批处理

---

您在这里学到的关键一课是，您的分支策略/方法是SCM中最重要的事情之一。一年半前，我们从StarTeam迁移到TFS，当我们迁移到TFS时，我们花了大约4个月的时间修改我们的分支方法，直到我们找到适合我们的环境和开发流程的方法

他们似乎将所有更改分支，而不仅仅是自己的更改集，这有什么原因吗

---

合并对话框专门询问您是要将所有更改分支到特定版本，还是只分支到特定更改集。如果您选择后者，那么您可以选择您的更改，而不需要接受每个人的代码。假设每个开发人员都在处理一组不重叠的文件，那么这不应该给您带来问题。

我已经读到，应该避免樱桃采摘。其中一个用户更像是一个网络管理员。i、 e.他主要在.aspx页面中使用HTML和CSS，并对整个站点目录结构中的大量页面进行小的更改，因此文件不会重叠，但目录重叠了很多。我认为cherry为他挑选更改会非常乏味，因为每当另一个用户在他的更改集之间有更改集时，即当他无法选择自己的一系列更改集时，他必须一次合并一个更改集。谢谢你的回复。真的是我们的网站管理员让这件事变得困难。他主要更改HTML和CSS，但他正在更改目录结构中的.aspx页面。在大多数情况下，开发人员可以将他们的项目划分到不同的文件夹中，共享代码除外，但由于我们有一个web管理员负责.aspx页面，因此无法将他的工作划分到不同的文件夹中。是的，我们可以通过迁移到像ASP.NET MVC这样的体系结构或将代码放在不同的文件夹中来实现这种分离，但遗留代码的基础非常庞大，这需要几个月的时间。我们目前没有采摘樱桃。我们总是合并最新版本的文件。我曾考虑过将自己的开发分支交给web管理员，然后他可以将其合并到QA中，但这似乎是错误的

---

就像解决这个问题需要引入很多复杂性一样——例如，开发人员必须每天至少定期从QA合并到开发人员一次，以获得web管理员的更改。谢谢你的回复。网站管理员的分支是完全合理的。关于从QA到DEV daily的合并，这是一个很好的实践，他们应该能够从他们的解决方案资源管理器右键单击get latest来完成。这是我让我们的开发人员这样做的方式。