Conflict resolution of course depends on actual content. Source code could be among most tricky ones to auto-resolve or detect when manual merge is necessary. D

Conflict resolution of course depends on actual content. Source code could be among most tricky ones to auto-resolve or detect when manual merge is necessary. Documentation, art and other not-so-strict content could be more auto-resolvable than source code. Git is here simply a mechanism for allowing different work flows. Your web app should enforce best practices for non-expert users. The added benefit is developer familiarity with git concepts. I wasn't familiar with OT and CDRT, so maybe I'm off the mark. They seem to try to solve real-time collaboration between multiple users editing same part of same document. This would always require some meta-document or meta-channel where users coordinate what should be changed, in what way and who does what. I would argue that git model is better: user decides when to pull and when to push changes, and the communication between collaborators is outside the scope of the versioning system. Collaboration is just one application. Even single-user content creation could vastly benefit from built-in versioning. This would eliminate some mental burden and usage friction (tagging), and open up more possibilities to experiment with different directions (branching). The feeling you get when you check-in working version of your code and you are now free to break stuff, that kind of feeling is missing when creating slides, graphics, music, CAD design...