这样是把体验版当开发版来使用了。

这样的话，你怎么保证你不会因为人为的错误使用了你正式版的小程序的 appid 去提交了测试版的代码

难道不应该是，

A 开发功能上开发版，测试通过，合体验版

B 开发功能上B的开发版，测试通过，和体验版

正式发布时，测试在体验版做功能回归测试，然后发正式版。

而且版本控制这种东西都交给 git 。

你们需要的是一个好的工作流

你指的体验版是哪个版本的时期？是开发版本的时候吗？我觉得我理解的开发版和体验版，和你理解的不太一样呢

我们在开发的过程中，不同的appid对应的是不同的游戏id和服务器接口，只有正式服的appid才会和正式服的游戏id和服务器接口完全匹配，所以不可能会出现正式的小游戏appid提交到测试的版本，这样的话他自己本地都没办法跑起来。

如你所说的话还有另外一个问题，就是当A开发完，B也开发完，但是这两个功能不是一起上线的话，有一组就需要等待另一组的测试和修复bug了，这个等待时间也很尴尬。因为需要使用同一个小游戏测试。我们的版本是git控制，但是问题点是在于并行开发的时候只是使用一个小游戏就会有时间等待问题。如果并行开发，并且有两个小游戏可以一起测试的话，就会加速功能的开发啊。之前的那种做法不是挺好的吗？为什么又去掉了呢？

有点不太理解。不过结合你说的，我的理解是

如果AB组同时开发两个功能，同时做完但是不在用一个版本更新的情况下，先上的功能A确实应该先测试，功能B应该等待，否则同时独立测试是没办法确保AB合并以后不出现问题的。

等到功能A测试完毕合并到主版本以后，再在有功能A的情况下测试功能B。

如果说AB功能本身就是独立的，有A的时候没有B，有B的时候没有A，那这种情况应该不太常见吧，因为游戏代码应该只有一套。

微信开发版是可以有多个的，但是体验版只能有一个。实际进入到测试环节的一般是体验版，但是开发版运行效果也可以做为参考。测试通过的体验版才可以提交审核，而且一般开发人员只有上传代码的权限，策划或者制作人有选择体验版和提审的权限。

开发版有多个是啥意思？哪个算是开发版？哪个算是体验版？我现在有点不太明白

你们有用小程序助手吗

你们游戏的开发都是使用一个小游戏账号吗？ 一个游戏两个组同时开发两个活动，完全都是独立的，这个很常见吧？