版本管理与分支策略
自动关联目录：版本管理与分支策略
1. 定位
UE 项目的版本管理难点只有一个：二进制资产不能合并。.uasset、.umap 冲突时只能二选一， someone 的工作会丢。
一句话定位：分支策略的设计目标是"让两个人不必同时改同一个二进制资产"，而不是"让大家尽量用同一个分支"。
2. 关键机制：One File Per Actor（OFPA）
OFPA 把每个 Actor 存成单独的文件，这样改 Actor 不需要签出关卡文件。它是 World Partition 紧密配合的四个特性之一。
| 无 OFPA | 有 OFPA | |
|---|---|---|
| 关卡文件 | 一个巨大的 .umap | 每个 Actor 一个文件 |
| 改一个 Actor | 必须签出关卡 | 只签出该 Actor 的文件 |
| 并行编辑 | 困难 | 可行 |
启用 OFPA 是大世界团队协作的前提。详见 World Partition。
3. 减少冲突的其它手段
| 手段 | 说明 |
|---|---|
| 拆分资产 | 大资产拆小，降低同时改的概率 |
| 数值外置 | 常量放数据资产/数据表，改数值不碰蓝图（见 大型蓝图项目组织） |
| Data Layers | 按层划分职责（见 World Partition） |
| 文件锁 / 独占签出 | 二进制资产的常规做法 |
| 约定工作时间 | 土办法但有效 |
4. 分支策略的常见模式
| 模式 | 适用 | 代价 |
|---|---|---|
| 主干开发（Trunk-based） | 小团队、高频集成 | 需要强自动化保障 |
| 功能分支 | 常规 | 合并地狱（尤其二进制） |
| 发布分支 | 有长周期版本 | 维护成本 |
| 多仓库（引擎/内容分离） | 大型项目 | 同步复杂 |
UE 项目的一个特殊约束：引擎源码与内容资产的变更节奏不同，很多团队会把两者分开管理。
5. 与二进制资产相关的实践
| 实践 | 说明 |
|---|---|
| 独占签出（File Lock） | 二进制资产用锁而不是合并 |
| 及时同步 | 减少长期分叉 |
| 小步提交 | 降低冲突面 |
| 提交前验证 | 见 构建农场与 CI |
| 明确所有权 | 谁负责哪块资产 |
6. 代价与权衡
| 设计 | 收益 | 代价 | 什么时候不该用 |
|---|---|---|---|
| OFPA | 团队可并行 | 文件数量暴涨，源码管理与 CI 要配套 | 单人小项目收益有限 |
| 独占签出 | 不会丢工作 | 可能阻塞他人 | 无冲突风险的资产不必 |
| 功能分支 | 隔离 | 二进制合并地狱 | 短周期改动不必开分支 |
| 主干开发 | 集成早 | 需要 CI 兜底 | 没有自动化时风险大 |
| 拆分资产 | 冲突面小 | 资产变多 | 过度拆分也不好维护 |
7. 踩坑与排查
| 坑 | 现象 | 怎么验证 |
|---|---|---|
| 没开 OFPA 却多人改关卡 | 频繁冲突丢工作 | 开启 OFPA |
| 数值硬编码在蓝图 | 改个数也要签出蓝图 | 外置数据 |
| 长期分支不合 | 合并爆炸 | 缩短分支周期 |
| 二进制资产用合并而非锁 | 冲突后二选一 | 改独占签出 |
| CI 没配就主干开发 | 主干经常坏 | 先建 CI |
| 没人负责某块资产 | 都改/都不改 | 明确所有权 |
8. 排查顺序
1. 团队能不能并行改场景？→ OFPA
2. 冲突集中在哪类资产？→ 拆分 / 外置 / 独占签出
3. 分支是否长期不合？→ 缩短周期
4. 有没有 CI 兜底？→ 见构建农场与 CI 篇参考
- World Partition（OFPA） · 大型蓝图项目组织 · 构建农场与 CI
- AssetManager 与 PrimaryAsset（数据资产）
许可协议：CC BY
作者：Davids
本文链接：https://hustjjd.github.io/074062eb.html
更新于：2026年10月10日