Unity协同开发核心就是版本控制 + Unity项目特殊配置 + 团队工作流规范。 Unity资源不是普通文件，有.meta元数据、场景/Prefab序列化、大量二进制资源（贴图、模型、音频），直接用普通Git会出现仓库膨胀、引用丢失、合并冲突爆炸等问题。

一、核心基础配置（必做）

1. Editor设置

Edit → Project Settings → Editor

1. Version Control → Mode：Visible Meta Files

必须开启。每个资源对应.meta文件，保存资源唯一GUID、导入设置；Unity靠GUID维护场景、Prefab之间所有引用。如果不提交meta，其他人拉取项目全部资源Missing丢失引用。

2. Asset Serialization → Force Text

场景.unity、预制体.prefab存为YAML文本格式，可以使用Unity自带UnityYAMLMerge智能合并；如果是Binary二进制格式，无法合并冲突，冲突只能二选一丢弃一方修改。

❗不要在Windows资源管理器直接移动/重命名Assets下文件，必须在Unity编辑器内部操作，编辑器会同步更新.meta；外部改文件会造成meta和资源不同步，产生坏引用。

2. 哪些文件夹需要提交版本库，哪些忽略

✅必须提交：

• Assets/ 全部资源，连同所有.meta
• ProjectSettings/：项目全局配置（Layer、Tag、渲染管线、Player设置）
• Packages/manifest.json：包管理器依赖清单

❌必须忽略，不要提交（这些可以本地自动重新生成）：

• /Library/：最大缓存文件夹，资源导入缓存，体积巨大
• /Temp/：编辑器临时文件
• /Obj/：编译中间产物
• /Build/ /Builds/：打包输出
• /Logs/：日志
• /UserSettings/：个人编辑器布局窗口配置，每个人本地不一样

项目根目录配置.gitignore，放在Assets外面，仓库根路径。

二、主流版本控制系统对比

方案1：Git + Git‑LFS（最常用，中小团队）

Git擅长文本代码，但原生不适合大二进制文件（模型、贴图、音频），会把完整文件每次提交全部存入历史，仓库体积飞速膨胀。 Git‑LFS（Large File Storage）：大文件存LFS服务器，Git仓库只存很小指针文本，解决二进制资源仓库膨胀问题。

.gitattributes（LFS追踪规则）

#模型
*.fbx filter=lfs diff=lfs merge=lfs -text
*.obj filter=lfs diff=lfs merge=lfs -text
#贴图
*.png filter=lfs diff=lfs merge=lfs -text
*.jpg filter=lfs diff=lfs merge=lfs -text
*.tga filter=lfs diff=lfs merge=lfs -text
#音频视频
*.wav filter=lfs diff=lfs merge=lfs -text
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.mp4 filter=lfs diff=lfs merge=lfs -text
#unitypackage
*.unitypackage filter=lfs diff=lfs merge=lfs -text

Git配置Unity智能合并UnityYAMLMerge Git遇到冲突的场景/prefab调用Unity自带UnityYAMLMerge.exe做语义合并，而不是普通文本乱合并YAML，减少大量冲突。Windows路径示例： C:\Program Files\Unity\Hub\Editor\2022.3.xx\Editor\Data\Tools\UnityYAMLMerge.exe

Git+LFS优缺点 ✅优点：免费，生态成熟，程序员熟悉，GitHub/GitLab/Gitee都支持LFS ❌缺点：美术同学学习成本高；LFS存储空间有额度；大项目拉取、分支切换速度一般；二进制文件锁文件需要额外工具。

方案2：Unity Version Control（Plastic SCM，Unity官方）

Unity原生深度集成，编辑器内直接操作，专门面向游戏团队。 ✅优势：

1. 原生处理大二进制，不需要LFS；支持文件锁（check‑out独占锁定），美术改场景、Prefab可以锁定文件，避免两个人同时改同一个文件产生冲突。
2. 内置UnityYAMLMerge智能合并；GUI对美术友好，不用记命令行。
3. 分布式+集中式两种模式。 ❌缺点：大团队付费；国内访问云端有网络问题；程序员对Plastic熟悉度低于Git。

方案3：Perforce(P4)

大型商业游戏大厂主流，适合百人级别超大项目；强文件锁，对海量大资源性能极强；配置运维复杂，个人小团队过重。

小团队推荐：Git+LFS；美术多不想学命令行优先PlasticSCM。

三、冲突来源和规避方案

Unity最头疼冲突来源：场景文件(.unity)、Prefab预制体。

1. 多人同时编辑同一个场景，是冲突重灾区

最佳实践：尽量拆分场景，不要所有人挤在同一个大场景。

• 主场景只放空框架，使用SceneManager多场景叠加；不同人员各自负责自己的子场景。
• 大量重复物体尽量抽成Prefab，不要直接堆在场景里。
• 大Prefab继续拆分小Prefab，减少多人同时修改同一个预制体。

2. 冲突处理 开启ForceText + UnityYAMLMerge智能合并，大部分简单冲突自动合并；

如果自动合并失败，不要手动直接编辑YAML源码，容易把场景改坏。优先选择保留一方版本，在编辑器重新手动修改。

3. 脚本C#文件冲突 普通文本冲突，和常规Git项目一样解决。

4. 禁止冲突来源：不要提交Library，不要提交UserSettings，不要外部文件管理器移动资源。

四、团队工作流规范（非常重要）

1. 提交粒度小，频繁提交，不要一次性提交几百个文件；写清楚commit注释。
2. 拉取更新前关闭Unity编辑器，拉完再打开；避免编辑器正在运行时外部修改大量文件导致缓存错乱、资源丢失。
3. 分支策略

• main/master主线：永远保证可以正常打开、可以打包。
• 每个人新建自己功能分支，开发完成合并回主线；禁止直接在main直接提交。
• 美术资源分支、程序代码分支分开管理。

4. 资源规范

• 资源全部在编辑器内部移动重命名；
• 删除资源也要编辑器删除，meta一起删掉，不要只删资源留下孤儿meta。
• 不要把测试临时资源提交主线。

5. 版本对齐 团队所有人统一Unity编辑器版本，统一Package包版本。如果版本不一致，打开项目会自动升级/降级资源，产生大量无用变更，造成大量冲突。

五、常见踩坑

1. 提交资源忘记提交.meta 现象：自己电脑正常，队友拉下来全部Missing引用，脚本丢失、材质空白。

提交前检查git status，新增资源对应的.meta必须一起被版本库追踪。

2. 把Library提交仓库 Library几个G大小，仓库直接爆炸。如果已经误提交：执行git rm -r --cached Library本地保留文件，从版本库移除，再提交。

3. 场景冲突，强行手动改yaml文本 YAML格式复杂，手写改错字段，场景打开直接损坏丢失物体。

4. Git LFS忘记安装 队友没有装git‑lfs，拉取下来全部是指针文本，贴图模型全部无法加载。团队每台机器都要安装Git LFS，执行git lfs install。

5. Unity版本不一致 A同学2022.3，B同学2022.2，打开项目会触发资源版本转换，大量文件被修改，产生海量脏文件。

六、和热更新/SDK的关联

1. Git管理工程源码资源（编辑器源文件）；Addressables打包输出AB包、HybridCLR热更dll是打包产物，不需要提交版本库，放Build目录忽略。
2. Plugins目录SDK原生库也纳入版本控制；不要提交打包后的APK/IPA。

简短总结

Unity协同开发三件套：

1. 编辑器配置：Visible Meta Files + Force Text；所有操作尽量在Unity编辑器内部完成。
2. 版本控制：二进制资源使用LFS/PlasticSCM，忽略Library/Temp/Build等可生成目录。
3. 团队规范：拆分场景、拆分Prefab，小粒度提交，统一Unity版本，分支开发，尽量避免多人同时修改同一个场景/Prefab。

如果你需要，我可以提供一份完整可用的Unity .gitignore模板。