I've worked on projects with thousands of developers committing to the same repo daily.

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).

2-3 people daily I would be completely surprised there's any issues.

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.

rerere has worked pretty well for me when handling conflicts and it’s built into git.

I’ve worked with hundreds of engineers in a single codebase. Never had any issues like you’re describing.

Rebasing is extremely easy with git. Sounds like more of a skill problem then a git problem.

I think the issue comes about more when you have refactoring going on at the same time, and suddenly multiple feature branch maintainers need to figure out if they're going to merge in the main branch, rebase onto the main branch, if it makes sense to squash their changes first before attempting either path, etc. If they get only partway through either one, it's difficult work to pause and resume, so that integration work is fundamentally hard to collaborate on or even really review.

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...

You can always merge feature branches together to check for conflicts