我负责在我不太熟悉的分支上进行一些重要的前向集成。我很乐意合并大多数冲突，但是我真的很想为我完成一些领域来降低合并错误的风险。我们在 Tfs 2010 上运行：我有哪些选择？
我们在开发人员之间交流更改的正常工作流程是使用搁置集，但 Tfs 不允许在解决合并冲突之前搁置文件……如果我想传递的是合并冲突本身，这很不幸。我知道 Tfs 2010 引入了共享工作空间的想法——这个功能可以用于多人解决合并冲突吗？
我们有一个地理分布的团队，所以很遗憾，我们不能直接走到彼此的办公桌前。如果共享工作空间不能帮助我实现这个目标，我有什么选择？
【问题讨论】：
标签： tfs workspace branching-and-merging
我们的团队通常会将该部分传递给主要从事该部分工作的开发人员，假设它是自包含的（此处的 IE 合并不会破坏 sln 内的代码）。然后，一旦完成，将进行其余的合并。当然是两个步骤；但是，它确保合并正确完成。
如果这不是一个选项，我们通常会让负责合并的人记下他不能 100% 确定的一个或多个文件，然后在合并之后，当然要确保项目构建后，他通过 IM 向团队发送文件列表/通过电子邮件发送文件列表，并要求主要处理该代码的人员审查更改。诚然，这个过程不是完全可靠的，但至少我们是这样处理的。
另一个解决方案，正如您所逃避的那样，是拥有一个 TFS 共享工作区，该工作区位于您的所有团队都可以远程访问并查看代码的服务器上。这是一个good article，描述了如何设置它。如果每个人都使用相同的共享工作空间/映射等，则更容易进行联合合并。
最后，想到的最后一个选项是选择保留本地版本（不要合并文件），假设它不会破坏构建，然后将其传递给另一个开发人员。该开发人员使用 TF Merge /force 可以强制进行合并，这将了解您选择保留本地版本的事实，此时其他开发人员可以解决这些合并冲突。
Shelving 和 Unshelving 用于代码审查，这就是不支持冲突解决的原因。或者正如 MS 所说：
与 Get 操作不同，它合并 两者之间可以调和的差异 文件的版本自动和 帮助您手动合并冲突， 取消搁置操作不 支持合并。通过删除搁置 您的工作区中的待定更改位于 代码审查的开始， 您可以放心，任何更改 您的审阅者对 搁置集，例如将 cmets 添加到 一个文件，不要产生合并冲突 在取消搁置过程中。
我理解他们为什么要这样做，但我同意你的观点，如果有一个 Merge 类型的搁置“类型”或类似的东西会很好。在处理具有复杂合并的大型项目时，它肯定会有所帮助。
【讨论】：