我刚与我的经理谈了一个关于我正在进行的项目的签到政策的谈话。基本上我试图编辑一个已经由另一个开发人员检查过的文件但我不能 - 我问我的经理为什么我们不能同时编辑同一个类，他给出了关闭该功能的原因： em>我们在开发人员编辑相同的Form（或在设计器中完成任何可视化的操作）然后检查它时遇到了很多问题。合并设计器生成的代码中的更改是很麻烦的 ... < / p>
当我写这篇文章的时候，我很难看出他们遇到了什么问题 - 他们确实在尝试检查之前得到了最新的代码？
有没有人遇到过与另一位开发人员编辑相同表格（或设计师中的某些内容）然后检查TFS的问题？如果是这样，你的团队是如何解决问题的？您是否也关闭了开发人员在同一个班级上工作的能力？
编辑：以下帖子（found here）正是我的经理所描述的问题。任何人都知道解决问题的方法比那篇帖子更简单吗？
答案 0 :(得分：3)
我认为你的问题的解决方案是建立源代码修改的最佳实践。
不鼓励人们进入UI代码并随意摇晃设计器中的组件。任何合理的UI修改都应该很容易合并。您最好的选择是尝试教育人们在任何给定的源控制系统中合并的最佳方式。此外，尽管设计师很有帮助，但是对于在后台自动生成的代码的无知，从长远来看将是非常有害的。
坚持按照您在帖子中说明的原因锁定签出文件的人通常会等待很长时间来检查他们的代码。当然，时间越长，修改的代码就越多，因此合并困难对于这些人。提前，经常和逐步检查需要人们分阶段思考他们的变化，对于一些程序员来说，这是一个相当痛苦的文化/心理调整。
答案 1 :(得分：2)
我刚刚查看了一些我的.designer.cs文件的历史记录，但我看不到任何会导致合并问题的更改。例如，没有批量重新安排代码。
要考虑的另一件事是确保每个人定期“最新”，然后任何单独的合并/解决方案都不会那么好，从而最大限度地减少出现任何问题的可能性。
调查第三方合并工具可能也值得考虑。周围有很多。
现在可能是我所做的改变与你所做的改变相比很简单，所以你应该把我的轶事数据带上一点点盐。
答案 2 :(得分：1)
当许多人同时编辑UI时，可能会导致问题（一般情况下）。合并逻辑可以很好地合并事物，但在很多情况下，UI是根据事物添加到表单的方式绘制的。您的UI可能会很快搞砸。
我不知道我是否会以此为借口全面执行独家检查。我可能会从一个（非程序化的）策略角度出发，该策略说明了业务逻辑的共享签出，但对于UI更改是独占的。
我会将其与强大的MVP，MVC或MVVM方法结合起来，这应该会限制必须同时触摸UI的人数。
正如其他人所提到的那样，记住SCM的一个开创性规则：早期和经常合并，你的问题就会减少。 （与此同时“在开始处理代码之前总是最新的。”