5.3 版本控制与团队协作：交接班记录本

5.3 版本控制与团队协作：交接班记录本

本节摘要：Git 是值班室的交接班记录本：谁改了什么、为什么改、出了问题退回到哪。但 Unity 工程不是普通代码仓库——二进制资产、场景序列化、Meta 文件都有独特的协作纪律。本节给出从仓库初始化到冲突处理的完整规范。

Unity 工程为什么特殊

普通软件项目里，Git 主要对付文本代码，合并冲突多数能自动解。Unity 工程里情况复杂一层：场景与预制体是巨大的 YAML 序列化文件，几十个对象排成一列，两个人同时编辑同一个场景，合并几乎必然打架；贴图、模型、音频是二进制文件，Git 存不了差异只能整份替换，仓库体积膨胀极快；还有元数据文件（同名加点 Meta 后缀）记录资源标识，它丢了资源间的引用就断，因此必须与资源同进同出。

这决定了 Unity 协作的两条基本盘。其一，文本资产序列化格式强制开启（编辑器资产序列化设置选 Force Text），否则场景文件是二进制，Git 完全无法合并；其二，可见性元数据（Version Control 模式选 Visible Meta Files）保证 Meta 文件随工程走。这两项设置是新仓库的第一天任务，晚一天就可能有人提交了不可合并的版本。

仓库的三层防线

第一层是忽略清单：临时文件、库缓存、构建产物绝不入库。Unity 官方维护着一份标准模板，核心内容如下：

# Unity 自动生成的临时与缓存目录，一律不入库
[Ll]ibrary/
[Tt]emp/
[Oo]bj/
[Bb]uild/
[Bb]uilds/
[Ll]ogs/
[Uu]ser[Ss]ettings/
MemoryCaptures/

# 本机个性化配置
.vs/
.idea/
*.csproj
*.sln

# 打包产物
*.apk
*.aab
*.unitypackage
​

第二层是仓库管理大文件的锁与存（Git LFS）：贴图、模型、音频等二进制资产交给 LFS 追踪，主仓库只存指针，克隆与拉取速度才能维持在人类可接受的范围。第三层是分支模型：主干保持可运行，功能在独立分支上开发，完成自测后合回——Unity 项目尤其依赖"主干永远能开"这条纪律，因为美术与策划的资产依赖运行验证，主干一坏全线停工。

动手：一次真实的冲突处理

背景：策划与程序同时改了 GameManager 预制体——策划调了数值，程序加了组件。拉取时 Git 报冲突。

操作：冲突发生在场景或预制体的 YAML 文本上，处理流程如下：

1. git status 确认冲突文件清单，只有一个人负责解冲突，其他人按兵不动
2. 打开冲突文件，搜索冲突标记，理解两侧改动：
   <<<<<<< HEAD
   （我方：数值 damage 从 10 改成 15）
   =======
   （对方：新增了 HealComponent 的字段段）
   >>>>>>> feature-heal
3. 判断：两处改动语义上不冲突，一段是数值、一段是新组件，都应保留
4. 删除标记行，拼接成合并后的完整段
5. git add 标记解决，提交合并
6. 回到 Unity 让它重导入，进 Play 模式验证：数值正确、新组件在列
​

结果：合并通过，Unity 里打开预制体确认策划数值与程序组件同时存在，运行无异常。

解读：这次能顺利合并，靠的是改动区域分离（数值段与组件段在文件不同位置）。真正的死局是两人改了同一行——比如都把 damage 改成不同值，Git 无法裁决，必须人来定。Unity 场景文件的可读性差，解冲突前先用"拉一下最新版、开着旧副本对照"的方式确认双方意图，比直接在标记之间乱拼安全得多。预防远胜治疗：按工位划分场景归属（每个人拥有自己的场景或预制体，公共预制体指定唯一维护人），冲突率会降到接近零；实在要协作编辑同一场景，锁定工具或拆分 Additive 子场景是两条现成的出路。

变式：把上述纪律固化成合并前的自动检查——提交钩子里跑一次批处理模式（命令行无界面模式）的项目打开校验，场景或脚本编译不过就拒绝提交。配置成本一小时，换来"主干永远能开"的自动保障。

场景与预制体的协作细则

把"按工位划归属"落成可执行的细则，有三条经验可循。第一条，场景拆分是治本之道：与其五个人共用一个大场景，不如切成主场景加若干子场景（叠加加载），每人认领一个子场景，物理上就不存在同文件冲突。第二条，预制体的修改权要单点化：公共预制体（玩家、敌人、UI 组件）各指定唯一维护人，其他人要改属性，提交申请而不是直接动手——预制体被两人同时编辑后的冲突，比场景冲突更难解，因为它的 YAML 更长更密。第三条，提交前扫一眼变更清单：Unity 会把大量无关的资产改动（重导入、元数据刷新）混进提交，养成"逐文件确认再暂存"的习惯，仓库历史的可读性完全不同。

还有一个专项注意：批量改名与移动资源要在 Unity 内进行、一次一事、单独提交。资源移动会牵动场景与预制体里的所有引用，如果与其他逻辑改动混在一个提交里，出问题时既难回滚也难定位。把"结构性变更"（移动、改名、重导）与"功能性变更"（逻辑、数值）分成两类提交，是 Unity 仓库区别于普通软件仓库的一条特有纪律。

提交纪律与值班记录

Git 的提交信息就是值班记录，写法只有一条铁律：让三个月后的同事看标题就知道这次改动动了什么、为什么。推荐"动词加对象加原因"的短句式，例如"修复金币重复计分：触发回调改走状态机"。附带三条小纪律：小步提交（一次提交一件事，回滚才有的放矢）、不提交运行中产生的改动（彩排规则对资产无效，改了材质记得确认是不是真想提交）、合并请求（Pull Request）里附验证方式（"已真机验证跳跃手感"），让审查者不用猜。

另外交代一句 Unity 曾经自带的协作服务（Collaborate，后并入 Planner 系产品线）：它简化了提交与回滚的界面，但扩展性与分支能力不及标准 Git，两人以下小团队可作起步选择，五人以上直接上 Git 加托管平台，省得中途迁移。选择托管平台时再补一条工程判断：优先挑对 Git LFS 支持成熟、有构建流水线可挂的平台，Unity 项目的仓库体积与打包验证都吃这两项能力，团队规模一大就是刚需。

本节要点回顾

• 第一天两项设置：强制文本序列化加可见元数据，否则以后不可救；
• 忽略清单与 LFS：缓存不入库，二进制走大文件存管，仓库不膨胀；
• 主干永远能开：功能分支开发，合回前自测，美术策划都依赖可运行主干；
• 冲突处理四步：确认清单、理解双方意图、手工合并、Unity 里验证；
• 按工位划归属：预防冲突的价值十倍于解决冲突。

制度立好，最后两节走出编辑器：打包出厂与上线排错。