Hi
@FrostyCat, what do you think the temporary solution for us working as teams? Is it as long as we create resources on one person and the others pull and edit only would be fine? We use github desktop, not GM's built in scm system.
I remember this was a thing back in 2017 but even until now I'm still searching and still can't find the solution yet.
Perhaps what we need is someone creating a simple 'guide' that references people how to work with multiple people using source control with GM, as in what works and what doesn't, since (I tried again earlier today) project corruption is still sooo frequent when merging...
The issue is this: I don't have a real answer for that myself.
The "one creating user" suggestion is just a hypothesis given my observations of the current file format behaviour, I have not tested it live to date. But if you are willing to try it out on your team and let me know how it pans out, I would be happy to listen in.
It really doesn't matter what Git client you use, the main problem is at the file level, not the interface level. You can reduce the incidence of with-versus-without-comma conflicts by installing
this command line tool, but the issue with UUIDs and created-versus-not-created conflicts remains. As long as you can commit, create branches, stash and pull correctly with the GitHub client, you are more or less the most prepared you can be. Though I would recommend learning some command-line Git for cases where visual GUIs often don't cut it.
Perhaps what we need is someone creating a simple 'guide' that references people how to work with multiple people using source control with GM, as in what works and what doesn't, since (I tried again earlier today) project corruption is still sooo frequent when merging...
I would love to write such a guide, and it's not like I haven't written similar documentation before. But given what happened during the GMS 1.x timeline, I have qualms about that approach.
The first issue was when I started creating workarounds for making the integration usable again. This isn't a best practice, but I know it'll happen for the guide to be actually applicable. Not only did it give YoYo room to be complacent and turn their priorities elsewhere, it also ended up being an informal "official" workaround solution. That impeded YoYo from implementing a proper fix, since that would break the workaround for community members who rely on it.
The second issue is how improvements on the source control front only work when YoYo's development direction isn't undergoing upheaval. I did once collaborate directly with YoYo in GMS 1.x's timeline, when I was invited to report 20-something source control bugs directly from in-house builds. The developer assigned to me during this blitz session did a stellar job. The source control compatibility of the GMS 1.x format and built-in integration skyrocketed. But later when I uncovered other incompatibilities, YoYo had no time for it anymore. GMS 2 development was ramping up, and I never got any attention on the source control front again.
The third issue is that I'm mainly a solo hobbyist/extension developer. If I write such a guide, my experiences and usual practices will differ significantly from my audience's. Everything you see from me, including that Mantis ticket, is just me creating small-scale hypothetical simulations in a basement. While that has some reference value, it is a far cry from genuine production-level experience, and it also arguably compromised the efficacy of my blitz session with YoYo. My best intentions would be to have no "let them eat cake" instructions in such a guide (e.g. manually checking UUIDs to make sure they line up is feasible in my small sample, but perhaps not in your project), but I know it'll fall short.
If this is to happen again, I definitely won't be doing it solo again. It will have to be done via community testing and consensus, and YoYo has to be on board with it.