工作区和（连接到服务器）解决方案有什么区别？答案

【问题标题】：What's the difference between workspace and (connected to server) solution?工作区和（连接到服务器）解决方案有什么区别？
【发布时间】：2020-02-21 08:53:02
【问题描述】：

我知道我应该在谷歌上搜索这样的主题，但我就是找不到清晰的文章。

我不明白的部分是，如果我只是在我的计算机上创建两个解决方案映射到同一个 TFS 文件夹，或者如果我创建两个工作区有什么区别？在某种程度上，我理解解决方案和 TFS 工作区之间存在差异，因为解决方案可以完全是本地的，并且不连接到任何版本控制。但是，我创建的工作空间是否总是在我的本地计算机中有解决方案？如果是这样，我真的不明白为什么我应该有这样的工作空间。

我不明白的另一件事是，在 VS 中打开一个解决方案后，我仍然可以在团队资源管理器和解决方案资源管理器中切换到另一个工作区（如果我之前的问题是肯定的，它总是在另一个解决方案中）。这背后的想法是什么？我觉得这样的操作很混乱。

顺便说一句，我实际上不确定工作空间是否是我正在寻找的东西。我想做的是：我在同一个开发分支的同一个软件项目上有多个任务。所以我希望能够在不影响其他正在进行的任务的情况下完成一项任务。以前我必须要么创建一个新的解决方案（当我需要使用不同的分支时，我实际上是这样做的），或者只是简单地搁置对一个分配的更改 -> 撤消挂起的更改 -> 对其他分配进行更改。有人告诉我工作区是解决方案，但是在阅读了一些文章后，我仍然不知道如何使用它。

【问题讨论】：

我在 2017 年（接近 2018 年），我仍然不确定以您描述的方式在 VS 中处理任务管理的最佳工作流程。我发现了这个问题，因为我一直在搜索并尝试使用工作区功能无济于事。我想知道问题的一部分是否是由于我有义务使用 IIS Express，但在我看来，我不能在不同的工作场所处理两个任务，同时在本地调试浏览器中的这些单独的变更集，而无需切换我的整个解决方案。这是基于分支的工作流程的时代，我不敢相信我仍然需要搁置。
如果您找到了一个工作流程来解决您在发布本文时遇到的问题，我很想听听您是如何在多组待定更改之间管理本地工作的。跨度>

标签： visual-studio tfs

【解决方案1】：

TFS 工作区定义了哪些更改控制文件和文件夹并映射到本地文件和文件夹（因此特定于用户和机器的组合）。

VS 解决方案定义了一组项目及其相互依赖作为一个单元工作（通常用于创建一个或多个可执行文件和库的单个软件产品）。

这些概念是正交的。一个工作区可以包含多个文件夹，每个文件夹位于一个单独的文件夹中。

除非您希望能够同时处理多个需要单独签入的不同事物，否则我强烈建议您避免使用多个工作区，直到您对变更控制更加熟悉为止。虽然在某些用例中多个工作区是一种强大的方法，但它确实增加了复杂性。

同样，我建议避免使用包含多个解决方案的单个文件夹，这不是 VS 默认运行的方式，需要仔细管理以避免出现问题。

【讨论】：

感谢您的回复。很抱歉，但我不确定我是否理解您回答中的“文件夹”概念。 “一个工作区可以包含许多文件夹，每个文件夹都位于一个单独的文件夹中”。 “同样，我建议避免使用包含多个解决方案的单个文件夹”。它是指本地计算机“文件夹”（如果是这样，我不明白你描述的场景），还是在 TFS/VS 术语中有一些特殊含义？事实上，“能够同时处理多个不同的事情，你需要单独签到”正是我想要做的事情
我想我可以通过将多个本地解决方案映射到同一个 TFS 文件夹来实现这一点，每个解决方案对应于我的一项任务。但是我只是不知道工作空间是做什么用的，如果我可以在不知道工作空间存在的情况下做我描述的事情
@tete re。您的第二条评论：我不确定您要做什么。 “解决方案”是VS的东西，在TFS中没有特殊含义（它只是一个文本文件）。如果您想同时处理多个任务（分配），您最好将 TFS 中的同一个文件夹通过不同的工作空间映射到您工作机器上的多个位置（这样您就可以签入一组更改而不影响其他更改）但是 这不是一个好习惯。最好有较小的任务（也许每个任务都有助于不同的主任务）并一次完成一个任务。也节省了合并。
@Richard 感谢您的回复。现在我的理解是工作空间和解决方案从不同的角度来看是不同的东西，即使实际上如果你想修改代码并且如果你想在 VS 中进行修改，你必须将一个本地解决方案分配给一个工作空间。对于我，这说得通。但是我仍然认为，当您已经打开分配给一个特定工作区的一个解决方案时，让所有工作区都可以使用 Team Explorer 视图会令人困惑。错误的工作空间很容易出错。（我想这是您建议避免使用多工作区的原因之一）
@Richard 关于避免使用多工作区，我对当前的 VS 安排并不满意，正如我在之前的评论中提到的那样，但我想它更像是一种软件开发方法，它是有多项任务很常见，而且每个任务都无法在数小时内完成。因此，只有在完成另一项任务后，我才能真正开始一项任务。我想这种情况在我们这样的小公司中并不少见。我觉得这个开发过程没有错，只是工具对它不友好。

【解决方案2】：

这些现在有点老了（因为他们不谈论本地或服务器工作区以及公共或私人设置）但我写了几篇关于工作区的博客文章可能会有所帮助：

另外，Professional Team Foundation Server 书中的版本控制一章应该会有所帮助。

【讨论】：

感谢您的文章。所以我可以肯定地说，如果我想同时执行多项任务并且不希望对一项任务的更改影响其他任务，那么我应该拥有多个工作区吗？在那种情况下，一个解决方案对应一个工作空间？顺便说一句，我发现我可以打开一个解决方案（工作区）但对另一个工作区进行一些操作（不是代码修改，而是例如文件操作），这非常令人困惑。在某些时候，我明白即使使用 TFS，解决方案和工作区也不是同一件事。但是修改错工作区还是很容易出错。