【用户文章】P4合并实践指南之实例拆解Resolve
来源：向华 作者：龙智 发布时间：2022-07-14
冲突的发生原因
有两种常见情况会导致冲突的发生：一是当你尝试从一个分支合并文件到另一个分支时；二是当你 check out 了一个文件并做了一定的修改，在提交前，另一个人已对该文件进行修改并完成了提交。
这里提到的修改，可能是文件内容上的，也可能是文件属性/类型上的，当然也包括更改文件名或新增和删除文件这类变动。
当冲突发生后，P4 会要求你必须解决这些冲突，才能允许提交。
而冲突尚未解决时，永远会在文件图标上显示一个红色的问号。
冲突解决的 3 种原子性方式
与其他 VCS 类似，P4 针对 Resolve Conflict 有三种原子性方式：
Accept Source：目标文件将会被覆盖成源头文件的模样。 Accept Target：目标文件将不变。 Accept Merged：如果没有冲突，将会合并源头文件和目标文件之间的变化，最终形态是一个大融合的结果。
在用 P4V 的朋友应该了解，右键点击带有冲突标记的文件-选择 Resolve 后，会弹出下图对话框。这里能够可以看到这 3 种 Resolve 方式。
用实例说明几种典型场景
实例二：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。
结语
题图：2022-06-21 杭州晚霞 By HZ全智贤
如需免费试用Perforce Helix Core，请立即联系Perforce授权合作伙伴——龙智：
电话：400-775-5506
邮箱：marketing@shdsd.com
