I used the same setup and was also frustrated. I replaced Orgzly with Orgro [0] which can only view files but works much better for my purposes.

[0] https://github.com/amake/orgro/

It helps a lot if you have a third machine, which runs 24/7. Haven't had any sync conflicts in ages.

Same, added an always-on Raspberry pi + zerotier to the mix and got rid of the sync issues between my phone, laptop and workstation all at once.

I wish there was something to make some sort of CRDT for modeling org though. I feel that the operation that ended up causing text conflicts in the past had obvious resolutions with the right structure and Metadata, but yeah, resorting to having a peer always on gets around it more easily that writing my own thing and deviating from emacs and orgzly

Funnily enough, crdt.el exists. I've tried it for org-mode syncing and the only thing that broke it was having a Windows Emacs connected to the session. It felt like line endings weren't getting handled properly, but I got frustrated with it and gave up in favour of Emacs in a tmux window on a raspberry pi behind my monitor.

What does the third machine do?

It's a read-only peer with a huge disk which is always on and syncs changes across all devices continuesly. This way you can safely change the same file across all devices, without them having to be online simultaneously.

It would minimize the synchronisation lag between the other machines, being more often started.

The approach I use is to have a single incoming notes file for my phone. I then refile those notes into the correct location on my laptop later. It works for me because I realised that when I want to take a note on my phone I usually don't have time for a complete note, so the extra refile step gives me the opportunity to fill it out more at my leisure on my laptop. As an extra benefit though, it means that I only have one file that can conflict, and I can just bias resolution towards the phone's version.

This is how I also do it, and with ediff-files it is fairly quick to resolve whatever conflicts inevitably come up anyway.

There is now a native Git repository type, still in beta though.

It's not going to get added unless someone like you, who has that problem, sits down and writes a working code that solves it.