how to manage Drupal team with multiple developers of Drupal working collaborative on a large scale project

I've found that this is a very hard question to answer because the requirements are different between organizations and projects. That said, I'll give an overview of how we're tackling this problem.

Outside of Drupal itself, we use a combination of Jenkins, drush, bash scripts, git and git hooks to control the flow of work from development up to production. While git is thought to be "distributed" you generally will end up with a central server when working with a group. Our central server will fire off a shell script, based on which git branch was just pused, that tells Jenkins to perform some tasks. If code is pushed into our development branch then Jenkins will build the site from scratch by checking out the code from git, enabling modules and configuring things as they should be configured. Once that is done, Jenkins will take a backup of our production server and then apply the new code to that in a programmatic fashion using a shell script that is similar to the one used to build the site from scratch.

In order for the entire system to work, we force ourselves to make all configuration changes using code. To do so, we use a combination of features (features module), strongarm, drush, direct SQL manipulation and an upgrade helper module that has some update hooks in it. All of our code and web configs sit inside one large git repository, including Drupal core, all contrib, custom and feature modules. When we need to upgrade Drupal core we use drush and then commit the changes to our repo.

By ensuring that all configuration changes are in code or can at least be manipulated using some script we simply push our work up the dev->staging->production stack and we don't have to worry as much what content has been added to the live site. We're also able to repeatedly test how an upgrade will go on our production site because we can take a database backup and then apply the new code to it repeatedly. Once we're satisfied with the upgrade results we merge our changes into a "production" branch and push it into the central git server. A hook is then fired to actually upgrade the site.

There have been some issues along the way but for the most part it has provided us with the ability to control the dev->production process. There are caveats of course. It's very hard to revert a change, to the point where if something goes up that turns out to be broken, you can't revert, you must fix it by moving forward OR restoring from backup.

Hopefully this overview will give you some ideas on how to move forward. Most people I've talked to think our system is "the wrong way" but it makes sense for us and has worked really well. Go with best practices where ever you can, but don't be afraid to do things a bit different if it works for your needs.