It's hard to state a best practice as each implementation comes with its own requirements and ease of work. My own source control setup works heavily with continuous integration and allows for us to also have third party developers/consultants work side by side with our internal developers to ensure everyone stays on the same page. In regards to metadata, you can subscribe to whatever you want, it will just depend on how you are moving that from org to org. Our internal developers work with full copies of their orgs in the IDE (which we use MavensMate and SublimeText) and we have no issues with speed, but some of our external devs use Eclipse and only subscribe to what they are working on. We dont really care though, because what they submit to the repo will be merged with a full copy of metadata at multiple points in our process anyways. so for us, its important to have ALL metadata in the repo because repo changes actually build into a salesforce org using the ANT Migration tool.
I would say that a good start would be to identify what the goal of your project is and what you would like to get out of it. There are plenty of people here who can then steer you in the right direction to accomplish what you are looking for.
I have attached a little diagram showing the development process for what i have setup with my org. Developers all work off their own sandboxes and they commit to a developer sandbox meant entirely for merging code that devs are working on. When the commit is made and pushed, i have a feature which grabs that code and attempts a merge without actually merging(so metadata subscription is irrelevant because they are merging actual files in the repo where they build agent actually pulls from). This sends an automated alert to the submitter with a log of what failed in the commit. Once a commit "merges" successfully, a peer review is created where a team member will approve the merge. Once the merge completes successfully, we queue those changes until the end of the day where we push the entirety of all approved and passed commits to selected developer sandboxes (this does have its exceptions but i wont get into that part now. lol. )
QA pulls "completed tickets" of code from the merge org and performs initial testing. In our ticket management system, they can approve initial QA and we queue that commit to be moved to our User Testing/Final QA/Package Build org automatically based off its status. If the ticket passes User acceptance and package merge, the commits tied to that ticket are bundled with other commits on other tickets and builds the "deployment package". At the end of our sprint, our project manager selects the tested and ready to go issues and we build a deployment package to mark our completions for the sprint. This package is then deployed and tested against our Production Copy org. If all checks out clear, we send the exact same package to production and call it a day. Pretty much everything is automated and easy for every member of the team, and shows absolutely no bias on how a developer chooses to work with code or metadata.
I don't know if any of this is helpful at all, but hopefully it can help show that each org is different, and that the strategy you choose for your source control/continuous integration needs to be one that fits into your business. 
