In some ways yes, in some ways no. Large history can be an issue, but to get to that point you pretty much need to be doing something pretty special for a fortune 500 company. The entirety of the Linux Kernel clocks in at under 2GiB, the only company I've ever heard make the claim that this is an issue was Facebook, who went with Mercurial instead.
The trick with branches is that each represents a different feature or bug fix. So long as they don't touch the same bits of code, git makes merging them painless. Local branches allow for trying out ideas, and swapping between tasks easy. Remote branches allow for greater control. A common paradigm is only one or two people have commit access to master. Everyone else asks them to merge their branch.
This branch and merge strategy, called 'pull requests', is the key to github's success. On sourceforge with svn, I would have to generate a patch file, then send it to the developers somehow, then wait for them to examine it, before finally deciding to add everything as one large commit. This can take a while, especially if several things have to be modified. Worse, the developers have to revert their local code copy to a clean slate before applying the patch. With git and github, you can easily view what's going to change, and merging is a simple click/command.