我负责在一个我不太熟悉的分支上进行一些重要的前向集成。我很乐意合并大多数冲突，但我有一些方面可以帮助我减轻合并错误的风险。我们正在使用Tfs 2010：我的选择是什么？
我们正常的工作流程，用于在开发人员之间进行通信，以便使用搁置集，但Tfs在合并冲突解决之前不允许搁置文件...如果合并冲突本身我想要传递，这是不幸的。我知道Tfs 2010引入了共享工作区的想法 - 这个功能可以用于多个人来解决合并冲突吗？
我们有一个地理位置分散的团队，所以不幸的是我们不能只是走到彼此的办公桌前。如果共享工作区无法帮助我实现这一目标，我有哪些选择？
答案 0 :(得分：2)
我们的团队通常会将该部分合并到主要处理它的开发人员，假设它是自包含的（IE合并在这里不会破坏sln中的代码）。然后，一旦完成，合并的其余部分将发生。当然这是两个步骤;但是，它确保合并正确完成。
如果这不是一种选择，我们通常让合并负责人记下他不是100％确定的文件，然后在合并之后，并确保当然项目构建，他使用文件列表向团队发送电子邮件/电子邮件，并询问主要处理该代码的人员查看更改。当然，这个过程并不是完全证明的，但至少我们是如何处理它的。
正如您所提到的，另一个解决方案是拥有一个TFS共享工作区，该工作区位于服务器上，您的所有团队都可以远程访问并查看代码。这是一个描述如何设置的good article。如果每个人都使用相同的共享工作空间/映射等，则更容易进行联合合并。
最后，我想到的最后一个选项是选择保留本地版本（不要合并文件），假设它不会破坏构建，然后将其传递给另一个开发人员。该开发人员使用TF Merge / force可以强制进行合并，这将导致您选择保留本地版本的事实，此时额外的开发人员可以解决这些合并冲突。
Shelving和Unshelving是代码审查，这就是为什么不支持解决冲突的原因。或者如MS所述：
与合并的Get操作不同 可以调和两者之间的差异 自动和文件的版本 帮助您手动合并冲突， 不利的行动没有 支持合并。通过删除搁置 来自工作区的待定更改 代码审查的开始， 你可以放心，任何改变 你的评论家对 shelveset，例如添加注释 一个文件，不要创建合并冲突 在不利的过程中。
我明白为什么他们这样做但我同意你的意见，有一个Merge类型的搁架“类型”或者那种影响的东西会很好。在处理复杂合并的大型项目时，它肯定会有所帮助。