I’ve worked with hundreds of engineers in a single codebase. Never had any issues like you’re describing.
“git merge origin/master”
Done. Unless you have a conflict, then fix it and commit. It couldn’t be simpler.
If there’s value in this product, it won’t be because it’s somehow simpler than git.
And never mind maintaining an ongoing integration of multiple unmerged feature branches— perhaps that's more of a "front end" issue for GitLab and Github to solve, but the whole business of patchsets and the like is very much unsolved, and that's painfully obvious when you see Debian storing their quilt patches inside of of a git repo, rather than being able to leverage git's native capabilities to achieve those effects: https://salsa.debian.org/debian/netplan.io/-/tree/debian/0.1...
Git is far from perfect, but in my experience it's been far superior to any of the alternatives I used before it (cvs, svn, p4).
It suggests they're working on the same files and on the same lines, why??.
My current project has 40+ developers and I haven't seen a merge conflict in a long time.
Why do you think there's issues with merging and revising, pretty much all cloud solutions have a button to do both for you.
As soon as you have 2-3 people committing to the same repo daily, git falls apart fast. The biggest difficulties with git are merging and branch rebasing. If git could do rebases better, I would suspect software development teams to universally move about 20% faster.