That's not the problem. I actually like the git workflow, and I even prefer the very unixy way commands are named and work (compared to hg which was designed to appease svn refugees). The problem is that git's internals are ****.
Git's design is fundamentally incompatible with large scale development.
Do you know what large businesses need? Atomic commits across many projects, fine-grained permissions, sparse x shallow clones, large binary file support, and file locking.
Do you know what git fans' answer to this is? "Your organization is wrong". You don't need atomic commits across many projects, or shared code across projects, you need to silo engineers into internal vendors, bisect be damned. You don't need fine-grained permissions, you need fine-grained repositories. You don't need file locking, you need to man the **** up and draw your pictures in a text editor so you can resolve merge conflicts like a true member of the master race. And large binary files? Pfft, who would ever need to store binary files inside a source code repository? Like driver microcode, for example? Definitely not the dude who invented the ****ing flagship SCM that can't handle them, no sir!
If you are a large company and you use git, you are basically a trendwhore moron, because it's easily the worst tool for the job. Even subversion is better. Even Mercurial, which is basically the same thing, is better for this - after Facebook spent years hacking on it, mind you, and they only chose hg for this because they thought Git was basically an unfixable disaster. Microsoft literally had to rewrite git as a filesystem driver in order to make it passable for the Windows team. And what a ****ing waste of time, too.
I'm about ][ far away from writing my own SCM because Perforce is basically the software company equivalent of contracting pancreatic cancer, and yet it's still better for you than ****ing git.