【用户文章】P4 合并实践指南之实例拆解 Resolve

本文作者向华是资深游戏开发工程师，拥有 8 年游戏测试开发经验。他是前原神项目 P4 Admin，也是一名持续集成开发者。

作为Perforce Helix Core的用户，他结合自身项目实践经验，带来关于解决文件合并冲突的实操干货。

立即联系Perforce授权合作伙伴——龙智，获得更多关于Perforce Helix Core的咨询、试用、服务等信息。

接上文 P4Python：合并实践指南之如何脚本化integrate流程 提到合并的第二个关键步骤是 Resolve & Submit，Resolve 是做什么呢？简单讲就是解决冲突。

接下来，希望这篇文章能帮你捋清楚这是怎么一回事。

冲突的发生原因

有两种常见情况会导致冲突的发生：一是当你尝试从一个分支合并文件到另一个分支时；二是当你 check out 了一个文件并做了一定的修改，在提交前，另一个人已对该文件进行修改并完成了提交。

这里提到的修改，可能是文件内容上的，也可能是文件属性/类型上的，当然也包括更改文件名或新增和删除文件这类变动。

当冲突发生后，P4 会要求你必须解决这些冲突，才能允许提交。

而冲突尚未解决时，永远会在文件图标上显示一个红色的问号。

  冲突解决的 3 种原子性方式

与其他 VCS 类似，P4 针对 Resolve Conflict 有三种原子性方式：

Accept Source：目标文件将会被覆盖成源头文件的模样。

Accept Target：目标文件将不变。

Accept Merged：如果没有冲突，将会合并源头文件和目标文件之间的变化，最终形态是一个大融合的结果。

在用 P4V 的朋友应该了解，右键点击带有冲突标记的文件-选择 Resolve 后，会弹出下图对话框。这里能够可以看到这 3 种 Resolve 方式。

用实例说明几种典型场景

先来假设一下分支模型，假设我们有两个分支，主干 Main，发布分支 Rel。

这是一个最小开发模型，在 Main 上开发，在 Rel 上发布。

实例一：Rel 修复了一个 bug，需要合并该修复到 Main。

所有在 Rel 上的提交都需要合并回 Main。理想情况下，所有在 Rel 上的变更都需要及时合并回 Main。这里说的及时，是指提交 Rel 后的下一秒就 Merge 回 Main。

但现实往往并非如此，提交者提交到 Rel 后，会因为其他事务搁置合并操作，比如被叫去解决更大的 bug 或者参加会议。

这样，就会有很大概率，在 Rel 上因修复 bug 而改动的文件在 Main 上已经被其他开发新功能的同事提交了多次改动。

合并时遵循以下策略：

如果没有冲突，合并时选择 Accept Merged。

如果存在冲突，打开 Merge Tool，进行冲突解决操作。

如下图，Rel#2 到 Main#4 是通过 Accept Merged 合并过来，从结果上来看，Rel#4 融合了 Rel#2 和 Main#3 的改动。

Rel 上出现了这个 bug，Main 上一定也是有的，但修复方式可以不同。

线上的 Bug 修复通常是紧急临时、没有通过深思熟虑的，在 Merge Down 回 Main 时，甚至可以抛弃线上的临时修复方式，在 Main 上经过更长时间的准备以完成更稳妥的修复。

这种情况通常会灵活对待，比如 Resolve 可以选择 Accept Target，并在此基础上，对 Main 进行进一步的修复。

如下图，Rel#3 到 Main#5 是通过 Accept Target 合并过来，从结果上来看，Rel#3 被忽略了（Ignored）。

实例二：Main 上制作了新功能，需要发布到 Rel。

对于游戏业务，都有周期性更新的场景。

周期性更新的内容如果包含了线上未有的内容，此时就需要从开发分支集成进发布分支。

大多数情况，集成方式都选择 P4 Copy。

由于 P4 Copy 相当于 Accept Source 操作，会把 Rel 上的文件覆盖成 Main 上对应文件的模样，这里有一定风险。

对于新功能新模块的外放，大多数情况下可以放心 Copy。

如下图，Rel#1 和 Rel#5 分别是 Main#1 和 Main#7 Copy Up 而来，从结果上来看，Rel 上的文件此时完全等同于 Main 上对应的文件。一次完整发布就结束了。

但正如上文所述，Copy 的结果会将文件覆盖，操作前可以仍需观察前一个合并动作是什么，辅助集成的最终决策。

继续看上图，Main#6 到 Rel#4 是一次 Merge 操作，原因应该是暂时不能将 Main#2 和 Main#3 的内容发布到 Rel 上。直到时机成熟（比如周版本外放时间），Main#7 可以携带 Main#2 和 Main#3 的变更内容一起发布到 Rel，最终形成了 Rel#5。

这些细节，就需要提交者通过 Diff 判定 Copy 过去后，内容是否符合预期，再完成提交。

再次提醒，很多线上问题是携带了不该外放的内容而引发的。

就如图所示的 Main#2 和 Main#3 在 Main#7 之前都是未完成内容，无法直接 Copy Up 到 Rel。

实例三：尝试合并的 Revison 比最后一次完成合并的 Revison 要低。

有时候，我们可能会调整外放节奏（很多情况下是形势所迫），将一个尚未开发完成的功能模块先外放出去一部分上线。

此时就需要翻旧账了，找到过去的一次提交，将那次提交进行合并。

但这里要注意了，相关的文件可能在后面已经参与过合并很多次，当然这些合并都是小心翼翼的 Merge 操作。

继续看实例二的最后一张图，最后䘣完成合并的 Revision 是 Main#6，现在聚焦 Main#2 和 Main#3，我们需要提前外放 Main#2 这一部分的改动。

先考虑一下 Merge 后的结果，会在 Rel 上生成一个新的版本，这里是 Rel#5。Rel#5 需要是 Rel#4 和 Rel#2 的融合版本。

于是这个情形与案例一是类似的，中间的 Rel#4~6 的内容都能有所保留，只需要提交者打开 Merge Tool 进行谨慎选择。

别忘了 Diff。

结语

在本篇，通过实例，主要介绍了 P4 Resolve 的一些常见逻辑。

另外我们多次借助过去文章中提到的 P4V 内置工具 Revision Graph，来进行集成决策。

强大的 RevisionGraph 都有哪些方便的功能，我们未来再讲。

本篇结束。感谢阅读。

题图：2022-06-21 杭州晚霞 By HZ 全智贤

如需免费试用 Perforce Helix Core，请立即联系Perforce授权合作伙伴——龙智：

电话：400-775-5506

邮箱：marketing@shdsd.com