TFS 2010 - 重新调整分支基础时签出

发布于 2024-11-02 05:16:58 字数 169 浏览 11 评论 0原文

当我重新调整我们的分支基础时,团队的其他成员继续编写代码。 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

白日梦 2024-11-09 05:16:58

我认为你所建议的是一个相当标准的方法,只是为了确保我理解这个问题,这里有一个场景。

有一个 Main 分支。从此 Main 分支创建了 2 个开发分支(devAdevB),这些分支将用于对 2 个单独的代码进行更改项目。

devA 中的开发已达到稳定状态,并已合并到 Main 分支中。现在您想要将 Main 中的更改合并到 devB

devB 中,开发人员已经对更改进行了编码,并签出了许多文件。您不想让开发人员签入对 devB 的更改,并且您不想在变基发生时启动代码冻结。

如果自创建分支以来开发人员一直定期检查对 devB 的更改,那么当您尝试合并来自分支的 devA 更改时,您可能会看到合并冲突。 分支。熟悉这两个“项目”的代码和要求的人将需要帮助解决这些合并冲突。解决冲突后,您可能需要检查代码是否编译以及任何单元测试是否运行并通过。如果您有编译错误或单元测试失败,则需要进行调查。

一旦您对从 MaindevB 的合并成功感到满意,那么在 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 Main branch. From this Main branch 2 development branches have been created (devA and devB) these branches will be used to make changes to the code for 2 seperate projects.

The development in devA has reached a stable state and has been merged in to the Main branch. Now you want to merge the changes from Main in to devB

In devB the 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 to devB and you don't want to initiate a code freeze whilst the rebasing takes place.

If the developers have been checking in changes to devB on a regular basis since the branch was created, you will porbably see merge conflicts when you try to merge the devA changes from the Main branch. 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 Main to devB has been sucessful then the developers with files checked out in devB can start to check in changes. If the files they have checked out were not changed as part of the merge from Main then 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's project, then the changes could have a significant impact on devB. 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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文