我们新项目用的creator，用到现在感觉略坑，特别是配合使用方面，经常出现项目提交冲突，而且冲突之后根本就没有解决方法，不像代码，你可以看出怎么用的，应该怎么取舍，但场景文件全都是一坨数据，还有一团不知道代表什么的数字编号，冲突了根本就不知道怎么办，给我的感觉就是组件的编号是递增的，A加了一个组件，B也加了一个组件，A提交了，B获取下来，完了，嗝屁，两者冲突，总会有一个人的组件需要重做，求开发组重视这个问题，不然creator永远都只能作为单人开发者的工具了
你好，现在并不支持场景合并。请不要多人同时编辑一个场景。
之后我们计划增加场景辅助合并工具。
感谢建议，我觉得这事非常重要。
但另一方面，数据驱动一定是比手写代码来得更先进的。我们不能倒退回去手写代码方便合并的时代，而一定是正面解决问题，提供场景合并工具来解决。
@panli32811 多人同时编辑同一份场景的冲突问题应该是所有数据驱动类引擎都共有的，所以我觉得你最后一句说: " Creator 永远只能作为单人开发者的工具 " 有点过激了。因为如你所说的 A 和 B 共同更改一个场景的问题，在 Unity3D 和 Unreal 里也存在，并且解决冲突的方法也是需要由 A, B 两人协商，最后在冲突者的机器上将前人的修改手动修复。
@jare 提到的通过加入合并工具，以及通过优化场景序列化数据这两种方法都只能降低冲突合并成本，但是不能完美杜绝多人修改场景的冲突问题。
所以不仅 Creator 编辑器本身需要加强，用户本身也需要为多人编辑设计好的工作习惯。我们比较推荐的做法是在场景编辑过程中更多的将数据用 Prefab 的形式搭建，这样多个用户之间可以维护各自的 Prefab，而整个场景则交给专门的场景设计师去负责，通过人员上的合理分配去解决场景编辑冲突。
只要做法合理，在加上一些对计算机序列化知识的深入学习，我觉得是会跳出 Creator 是一个 “单人开发者工具” 的固有思维假象。毕竟，这是一个目前计算机数据设计上，所有厂商都在探讨，思考和努力解决的问题。
想法是好的，但我们小作坊啊，哪有什么专人啊，都是身兼数职的说
我的建议是尽量将文件碎片化，比如一个node就是一个单独的文件，节点关系可以用文件路径来组合
那样会导致提交版本时，一个场景可能要提交非常多个文件，管理起来成本更高。实现技术上还会有各种各样的问题。
想法是好的，但我们小作坊啊，哪有什么专人啊，都是身兼数职的说
@panli32811 这个就有些矛盾了。多人协作其实就是构建在人员合理分配，其发展方向到最后多半会是专员化。 而如果如你所说的，小作坊（独立小团队），那么实际上对工具的使用场景更类似于一人多职，那么其实更像你问题里所说的那样是更倾向于 “单人/少数人开发者” 。
我觉得你可以试试 Unreal, Unity3D 等软件按照你所描述的几个人都身兼多职然之后的冲突处理场景，保证你苦不堪言。相比之下，Creator 为了独立开发者至少还保留了 Meta 的文本融合条件，我觉得反而是对独立开发者更加友好的设计。未来，还是会如上面所说的，强化编辑器内的 diff 功能来完善冲突后的解决方式。
场景尽量将内容分成 prefab不同人修改不同的prefab,我还有一个希望提供meta文件binary形式，json文件太大，meta文件保存成binary减小包大小，unity中有此选项可选
meta 文件并不会进入最终成品，不影响包大小
creator里文件冲突的问题确实经常发生，经常很莫名其妙的出现冲突。或者更新下来后整个工程在creator里打不开了。 最近几个版本更新下来好像情况变好了不少。
另外提个建议，meta文件既然不能让人编辑的，能不能默认设置为隐藏呢，一堆文件看起来好烦。
最近我把部分编辑器内容要移交给策划的时候，冲突问题十分的明显。可以说只要程序员和策划都动过场景里面的内容，冲突的概率十分大，几乎一天下来，一更新一定会冲突。这一个月苦不堪言，又不好处理冲突。 这样多人没法协作啊。我估计后面程序员和做场景设计人员会打起来。
meta文件git关于换行符设置一下就不会有冲突了，还有就是 谁创建的文件 谁提交meta文件，不要提交别人忘记提交的文件的meta
目前请参考上面的答复。之后我们会推出更人性化的解决方案。