当我重新定位我们的分支时，团队的其他成员继续处理代码。 Rebase持续约1-2小时。当你右键单击要合并的文件夹时，我在合并上下文菜单中这样做，所以这里没什么特别的。
团队成员签出代码，更改代码但不签到。这种方法有哪些风险？这种情况的最佳做法是什么？您的团队如何处理此类案件？
答案 0 :(得分：4)
我认为你所建议的是一种相当标准的方法，只是为了确保我理解这个问题，这是一个场景。
有一个Main分支。从这个Main分支创建了2个开发分支（devA和devB），这些分支将用于更改2个单独项目的代码。
devA中的开发已达到稳定状态，并已合并到Main分支。现在，您要将Main中的更改合并到devB
在devB中，开发人员一直在编码更改并签出了许多文件。您不希望开发人员检查他们对devB的更改，并且您不希望在重新定位时启动代码冻结。
如果开发人员在创建分支后定期检查devB的更改，当您尝试合并devA更改时，您可能会看到合并冲突分支。熟悉两个“项目”的代码和要求的人将需要帮助解决这些合并冲突。一旦冲突得到解决，您可能需要检查代码是否已编译，并且任何单元测试都会运行并通过。如果您有编译错误或单元测试失败，那么这将需要调查。
一旦您对从Main到Main的合并成功感到高兴，那么devB中签出文件的开发者就可以开始检查更改了。如果他们签出的文件未作为devB合并的一部分进行更改，则文件将正常签入。但是，如果他们签出的文件已经作为合并的一部分进行了更新，那么TFS将启动合并冲突解决工具，开发人员需要先解决任何冲突，然后才能签入代码。
希望上述内容与您目前正在关注的流程非常接近？如果我错过了任何内容，或完全错过了这一点，请告诉我。
这不是很好，但它是一种常见的方法，也是我们使用的方法。
这种方法的风险在于你最终可能花费大量时间来修复合并冲突，特别是如果你有很多开发人员在大量分支机构中更改代码的代码库。
为了缓解任何问题，最好尽早和尽可能频繁地进行折扣。早期因为如果您将所有内容保存到Main项目结束，则更改可能会对devA's产生重大影响。通常是因为每个合并的冲突数量最小化，使冲突解决更简单，更不容易出错。
设置“持续集成”构建也会有所帮助，因为您很快就会看到编译问题。如果您正在使用TFS 2010，那么门控检查也可能会有所帮助。
我不是百分百肯定这会回答你的问题所以请告诉我，如果我错过了什么