Git was built for giant open source projects where you have dozens of contributors making unplanned code changes to an organically growing code base. That's not a use case for any well-managed enterprise. Pull requests come a few at a time and representing a few days work and are rarely stepping on each other. Every conflict can be worked out face to face very quickly. If I have to manage a large group of devs, I break them up by vertical so they're not on top of each other.
This is the thing I've never really understood about the common objections to merging and resolving conflicts in larger projects. Sometimes people talk as if that happens all the time and it's not scalable if you have hundreds or thousands of developers all working on some huge code base. But how do you even get hundreds or thousands of developers working on the same huge code base so they keep getting in each other's way? Where is the modularity and coordination?
It always sounds like this happens at a hellish organisation where some Agile consultant once came in and said not to bother with boring stuff like management or software architecture. These must be strange places to work, because reportedly they also need to be prepared for requirements to change significantly every 27 seconds, and not being able to deploy changes in minutes is an existential threat even though the new feature has barely finished running the automated test suite and doesn't yet have any kind of user documentation, knowledge among the sales and support teams, etc.
Personally I do find rebasing and squashing to be very useful in workflows that involve Git, but there are plenty of effective ways to run a project and use a source control tool that don't rely on a 100% linear history with GitHub-style pull requests for change management.
Some people talk about merge conflicts as something inherently bad, but that's a flawed perspective. Merge conflicts are a great feature of a version control system. Given that multiple persons changed the same line, conflicts are the easy way out.
Conflicts have only given me a hard time when someone did something out of the ordinary. Even very large and unstructured open source projects such as the Linux kernel will see people naturally gravitate to different parts of the code. It's not often a filesystem developer suddently change the networking stack, for example.
