I can answer based on how we work at Virya Group - our CTO Marco Dings has been writing these up in a series of articles: http://magazine.joomla.org/issues/issue-apr-2014/item/1842-practical-development-3-project.
We use Atlassian products - Jira, Stash, Confluence etc.
We set up our working environment as a vhost for each project - we're working on scripting this so it's quicker. So each developer has their own local 'playground', and we set up dev.clientsite.com, staging.clientsite.com and then their live site, clientsite.com.
Within the vhost, we have a directory - vcs - and the web root - www.
We use PHPStorm, and we install Joomla into the www directory, and map this to the corresponding web root on the dev/staging/live using remote hosts.
A repository is set up on the project for the client, into this repository we put anything that changes from the vanilla Joomla, and any extensions which are modified in any way, shape or form, including templates.
These are symbolically linked from the VCS directory back into the www directory - so the files 'live' in the VCS repository, but they appear in the www folder as linked files.
We use LESS with our template base, and follow a BEM structure which we have in a separate repository. This is cloned down for each project, and sym-linked as a new template. Any client-specific customisations are then unique to this project, but we can merge in any future changes to all our projects with ease.
Some people will version control the entire site, it really depends what you want to achieve. We're interested in what changes, and we have sole control over that. We create a customer-custom.css file which the customer can change, but everything else is off limits.
As for database version control, that's something we're looking into. We have played around with some options but haven't found anything that ticks all the boxes as yet.
We use a bunch of scripts to automate all of the above, which we're developing and tweaking as we go.
I hope that helps!