TFS 2010 - 重新调整分支基础时签出
当我重新调整我们的分支基础时，团队的其他成员继续编写代码。 Rebase 持续约 1-2 小时。当您右键单击要合并的文件夹时，我是通过上下文菜单中的合并来执行此操作的，因此这里没有什么特别的。
团队成员签出代码、更改代码，但不签入。这种方法有什么风险？对于这种情况，最佳做法是什么？您的团队如何处理此类案例？
While I am rebasing our branch, rest of the team continues working on code. Rebase lasts about 1-2 hours. I'm doing it from merge in context menu when you right click the folder to merge, so nothing special here.
Team members check-out code, alter it but they do not check in. What risks this approach has? What is the best practice for this situation? How your team handles such cases?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为你所建议的是一个相当标准的方法，只是为了确保我理解这个问题，这里有一个场景。
有一个
Main分支。从此Main分支创建了 2 个开发分支（devA和devB），这些分支将用于对 2 个单独的代码进行更改项目。devA中的开发已达到稳定状态，并已合并到Main分支中。现在您想要将Main中的更改合并到devB在
devB中，开发人员已经对更改进行了编码，并签出了许多文件。您不想让开发人员签入对devB的更改，并且您不想在变基发生时启动代码冻结。如果自创建分支以来开发人员一直定期检查对
devB的更改，那么当您尝试合并来自分支的devA更改时，您可能会看到合并冲突。主分支。熟悉这两个“项目”的代码和要求的人将需要帮助解决这些合并冲突。解决冲突后，您可能需要检查代码是否编译以及任何单元测试是否运行并通过。如果您有编译错误或单元测试失败，则需要进行调查。一旦您对从
Main到devB的合并成功感到满意，那么在devB中签出文件的开发人员就可以开始签入变化。如果他们签出的文件在从Main合并的过程中没有发生更改，那么这些文件将正常签入。然而，如果他们签出的文件在合并过程中进行了更新，TFS 将启动合并冲突解决工具，开发人员需要先解决所有冲突，然后才能签入代码。希望以上内容与您当前正在遵循的流程相当接近？如果我错过了什么，或者完全错过了要点，请告诉我。
这并不像它想象的那么好，但这是一种常见的方法，也是我们使用的方法。
这种方法的风险在于，您最终可能会花费大量时间来修复合并冲突，特别是如果您有一个庞大的代码库，其中有很多开发人员在很多分支中更改代码。
为了缓解任何问题，最好尽早并尽可能频繁地进行变基。早期是因为如果您将所有内容保存到
devA项目结束，那么这些更改可能会对devB产生重大影响。通常，因为每次合并的冲突数量被最小化，使得冲突解决更简单并且更不容易出错。设置“持续集成”构建也会有所帮助，因为您很快就会看到编译问题。如果您使用的是 TFS 2010，那么门控检查也可能会有所帮助。
我不能 100% 确定这能回答您的问题，所以如果我错过了任何内容，请告诉我
I think what you're suggesting is a fairly standard approach and just to make sure I understand the question, here is a scenario.
There is a
Mainbranch. From thisMainbranch 2 development branches have been created (devAanddevB) these branches will be used to make changes to the code for 2 seperate projects.The development in
devAhas reached a stable state and has been merged in to theMainbranch. Now you want to merge the changes fromMainin todevBIn
devBthe developers have been coding changes and have a number of files checked out. You don't want to make the developers check in their changes todevBand you don't want to initiate a code freeze whilst the rebasing takes place.If the developers have been checking in changes to
devBon a regular basis since the branch was created, you will porbably see merge conflicts when you try to merge thedevAchanges from theMainbranch. Someone familiar with the code and requirements for both "projects" will need to help resolve those merge conflicts. Once the conflicts have been resolved you'll probably want to check that the code compiles and that any unit tests run and pass. If you have compilation errors or unit tests fail then this will need investigating.Once you're happy that the merge from
MaintodevBhas been sucessful then the developers with files checked out indevBcan start to check in changes. If the files they have checked out were not changed as part of the merge fromMainthen the files will check in as normal. If however they have files checked out that were updated as part of the merge, TFS will bring up the merge conflict resolution tool and the developers will need to resolve any conflicts before they can check in the code.Hopefully the above is resaonably close to the process you're currently following? If I've missed anything, or missed the point entirely then let me know.
This isn't as nice as it could be, but it's a common approach and one that we use.
The risk to this approach is that you could end up spending a lot of time fixing merge conflicts, especially if you have a large codebase with a lot of developers changing the code in a lot of branches.
To mitigate any problems, it's best to rebase as early and as often as possible. Early because if you save everything up till the end of
devA'sproject, then the changes could have a significant impact ondevB. Often because the number of conflicts per merge is minimised, making conflict resolution simpler and less error prone.Setting up a "continuous integration" build will also help as you'll see compilation problems sooner rather than later. If you're using TFS 2010 then Gated Checking may also be helpful.
I'm not 100% sure that this answers your question so let me know if I've missed anything