你看看改了什么，只要uuid没改，其他关系都不大
我们也遇到这种问题，请问你们最终解决了吗？
麻烦问下 同一个项目上传到SVN需不需要上传meta文件，不上传的话有什么影响么？
我问一下 不同版本是不是没改文件也会对meta文件进行更改 现在团队有3个人 版本分别为1.7.0 1.10.2 和mac1.10.2 每次从git上拉下代码 都是更改meta文件 其实是并没有做任何修改的 这样 会不会我这边提交一下 他们那边又要提交一下 每次都是提交一大堆？
重命名后git 知道 可否读取git 的一些数据来 自检呢
能不能在项目目录放一个“影子”文件夹 。creator维持这个文件夹与真实文件夹目录结构一样，这个这个文件夹只放meta文件。 这样就干净很多了吧
你最后一句的观点，可以看出，你没参与过商品化的游戏项目开发。
那我毕业后的十年是在干啥？
额，刚从egret转过来cocos creator ，以前也曾经是cocos2dx使用者，目前看见项目会生成.meta用于维护项目的依赖，于是查了下查到了这里，我试着用3.8版本的creator里官方有个UITest的工程，打开后，尝试再打开某个资源的文件夹把这个资源的.meta删除了，然后回看工程情况，它重新针对刚才的资源生成了.meta，这个我不意外，但是原本引用这个资源的节点也没有错误，理论上重新生成这个uuid应该变了，但却不会因此而产生索引和依赖上的异常，那么我的问题来了，如果我不提交.meta，只是提交资源，让每个用这个工程的人都自己生成.meta，理论上不是应该也没问题吗？ 还是说我还忽略了什么
你删除了meta，就相当于删除了资源，重新打开，对于编辑器而言，相当于重新导入一个资源，新资源（这个资源和你删除的老资源，文件名相同，但Creator并不关心资源名），uuid自然不同。
看到有人挖坟，我看了下是meta的讨论。
meta这个设计，我觉得是cocos creator 照抄unity的问题。meta问题的根本就是文件本身需要uuid和元数据。但是为什么不用老式做法，uuid使用路径，元数据放到另外的一个配置文件里面呢。godot，ue这类的引擎都是用的路径。
使用路径带来的不方便的地方，只是移动资源位置会带来引用的破坏，但是可以只在引擎内部移动资源位置就可以了，而且这个操作也不频繁。
但是使用路径带来的好处太多了。包括可以实现虚拟文件系统，来做覆盖式mod/dlc的包，还有远程资源在cdn上保持路径，可以方便的查找和快速覆盖。
unity 就是因为这个uuid的设计，那个asset bundle 打包和路径无关，设计的就很别扭，后来搞什么addressable的，都是因为资源没有路径相关性，不能按文件夹这种自然的形式打包组织。每次给unity弄资源框架的时候都要弄资源–> ab包路径的反查表，烦的要死。这点上cocos的ab包设计的比unity的好，按文件夹组织并且有优先级控制。
meta这个设计真的是最糟糕的借鉴
mate文件对于资源查找问题太不友好了，每次找资源的时候，左侧资源管理器图片显示太小，不能一下子就找到，要一个个看才行，而且资源预览的功能居然只能看，不能拖动到UI上，也不能定位资源，真的不知道这个功能有什么用。 
资源预览无法拖到层级管理器创建节点的功能已经修复了，可以等 385 第二轮（大概周五或者下周会更新）再试一下