That would be a way to do enable Git merges. However, a Spine project can host multiple skeletons, whereas a JSON export represents only a single skeleton. Also, importing the JSONs can get tiresome.

What workflow do you apply to other binary files like images? You could apply the same to .spine files.

Hi, I am too interested. In my case, we have one project file with about 200 animations. Sometimes I (as a programmer) would like to tweak some small changes, but I have to go to the animation guy and tell him. And now there is also audio guy adding keys for sounds. I didn't find ideal workflow - right now we just need to tell each other who is working on the project and the others are blocked. But since spine project is only one file, I can't see much space for collaboration on one project. It could work with a file for every skeleton setup and every animation (similarly to Unity animations, where animator and animations are separated files), but I suppose that this might not be possible.

Another option is to copy the specific animations over to some master project. I am still thinking about it, but I think that would need some more complex command line tools, like import etc. so I can make some tool to bulk manipulate the project file (doing that manually from menu seems too clumsy to me). I see that manipulating the project file directly is not possible as it is in some proprietary format.

Hello!
We're currently in the process of trying to improve the experience for multiple users working on the same file, and you're welcome to join the discussion about it here if you have any suggestion: Skeleton locking · #436 · EsotericSoftware/spine-editor

I've worked in the past on projects that needed to be handled by different people at different stages, and we had this approach (similar to what was already described in the thread):

• We all worked using GIT, and we'd lock the file though it so that only one person at a time would change it.
• When the setup was ready, each animator started animating a copy of the file. Nobody was allowed to change the setup, only animate mode.
• When the animations were done, all the files returned to me and I imported them all one by one in the GIT file.
• If changes in the setup needed to be made, we'd first re-import all the animations. I'd make the changes because I was in charge of rigging, then distribute a new version to all the animators.
• Only the rigger added new skins, and the file was already set up by the time it was handed out to the animators.

This worked because we had only one person with the role of rigger, taking care of the main file, and different animators.
In the future, we'd like to facilitate the process from Spine itself, as you can read in the issue

Thanks for the update, that looks cool!
I will watch these threads for more info.

Could you please be more specific how you imported every animation one by one?
It means you have to delete old animation in the skeleton, import a new one (select skeleton and animation), right? Doing this often would be a nightmare.

One only had to delete old animations if there were problems with it to re-import it, otherwise we usually waited for the animations to be completed, we didn't import test or half made animations. Fortunately, since we had many different characters and files, we'd usually split the animators across files so each could lock one rather than have all the animators on one single character. So importing/deleting didn't basically happen. Just merging by import project>animation in my case.
I think assigning a character to only an animator in most cases was the sanest thing we could have done even though I still did all the rigs.

Hm.. interesting.
When thinking about workflows, I always want a workflow that doesn't block anyone in the team from changing anything. I always work with the assumption that everything can change anytime and we have to be ready for that - you know it is still an iterative process