但是项目要走的长远，并且高频次维护，一定得有一套开发效率，审查效率都可行的框架
如果经常变资源名称,用 a 就很舒服,不用改代码,用 b 就不舒服,要改代码,
如果经常变变量名称,用 a 就不舒服,因为要重拖,用 b 就很舒服,不用改变量的值,
要么制定规则限制资源或者限制变量,舒服但导致不灵活,一旦出现需要打破规则的地方,就巨难受
要么无限制,二者都经常变,灵活但是用啥都不舒服,太随意就太乱,容易把握不住
a和b就是按比重取舍,没有最优解,只有最适合具体状况
2赞
我觉得你可以把$换成下划线，更方便输入，你的+和-我就抄一下，我之前是用的_p排除，哈哈哈
使用A+B，比重偏向B。
因为有个问题，prefab是资源，而路径可以存储在脚本或配置表
热更时能减少资源量
prefab文件也是不小的
另外还得考虑多人协作，开分支时的同步难度，这个是重点中的重点
我再也不想多分支同步prefab了
别人指的是挂不挂组件的问题，你说的是什么？
不是说挂组件及组件中使用的节点定位问题？
挂组件是避免不了的，比如OnEnable和OnDestry这类生存周期也只能绑定组件才能做，
分歧在于：
1、节点使用FindChild还是直接引用？
2、除了生命周期相关的函数，其他逻辑是否分离到一个与组件没有关系的脚本上？
问题1的情况变更定位节点，需要修改prefab（将另外一个节点引用drop到绑定脚本对应的属性上），这会增加prefab的变更因素，
多人协作分支管理时，prefab分支间同步到目前为止是一个难题，增加一个变更因素就增加一个难度。
问题2在于，多个逻辑，需要绑定多个脚本，每增加一个脚本绑定那也会引用prefab变化，也同时带来非界面变化而导致prefab变化，
prefab变化也同时带来热更新量及同步问题，而仅仅绑定只提供生命周期的脚本，prefab变化可能会降低很多。
1赞
出现这个问题只能说是任务分配没做好，不过我支持的也是尽量不要直接用节点引用，除了频繁加载的预制体
不是任务分配问题
我们实际项目中，会时不时出现一种情况：
需求A，我开了分支dev_reqa，需要修改aprefab.pefab
需求B，我开了分支dev_reqb，大部分修改bprefab.prefab，但有个入口在aprefab.prefab上，我也要修改aprefab.prefab
分支dev_reqb完成了，集成回trunk，
dev_reqa每天同步trunk的时候，将需求B的修改aprefab.prefab带过来，这时dev_reqa上已经有aprefab.prefab的修改记录，这时aprefab.prefab就百分之百冲突了
这个工作我一般是合并分支后才做，没有遇到过你说的情况
哪个工作？
aprefab.prefab的合并？
涉及到需要自己修改的公共预制体的情况
冲突100%会有，区别在于是类似我们项目这种每天解决，还是集成回trunk时解决。
如果集成回trunk时解决，那等于将解决冲突的工作后延到集成时解决，这会增加集成时间的。
每天解决的话，集成是没有冲突的，因为冲突已经每天都处理好。
另外问个问题，如果集成时才解决冲突，那么怎么保证trunk的稳定性？因为你没办法保证冲突解决方式是正确的。
我们的解决方案是开发分支每天同步trunk，有冲突每天解决，分支能集成肯定是经过测试的，这时冲突也能经过测试确保没问题
我是放在合并后才修改公共预制体，根本就没有冲突，何来解决冲突？
那工作不能并行进行啊
需要自己修改的公共预制体也就一两个，多个人同时进行的概率本来就低，自己修改的时候通知其他人就行了，你要同时进行指定冲突，creator冲突本来就难搞，遇到冲突我直接还原，你合并冲突的时间都可以重新做一个了，说合并冲突的我感觉是没用过 creator 的人
1赞
如果是临时的一段时间是这样，比较理解，
但是长期都是这样的情况，那是不是就是需求的排期问题以及功能逻辑的关联度太高了，拆的不够碎呢
或者你们的项目只会有一个预制体有关联，
我只说我们碰到的情况，你说没用过就没用过吧。
与其天天合并冲突把自己整难受加浪费时间，还不如提前做好项目规划，如果你们项目涉及的公共预制体比较多，那么应该由指定的人员进行维护，而不是每个程序自己修改，我还是觉得你们项目管理没做好
2赞
天天合并冲突不至于。
就是共用prefab冲突还是少数，但少并不是就没有，就算合并一次都难受。
代码合并一点压力没有。
所以避免不了，就将prefab合并压力尽量转给代码侧，这是我们的选择。
近十个开发，各自需求分支同步并行，每个分支单独开发、解决各自冲突、测试，最后集成。
trunk是稳定的，prefab冲突也是少数情况，一个月也没两三次。
可能这种方式的管理不好，或者你们的方式更好，可以的话请指教，虚心学习
我一般自己项目用A方案方便偷懒
比较大的项目和别人一起弄就用B方案