I would like to know if it is practical, or even wise, to chain git repos together. The situation I am thinking of is where I have the git repos on a remote web server where the master branch is that which points to a separate development webroot structure which all my web developers can push their files for testing. Once everything checks out, and the website still functions as expected in development, a manager would review the changes and then use git from within the development structure to commit the changes to a production repos, on the same server, thus making the changes live.
The problem that I am trying to solve is that developers currently have access to the live website and push simple changes to it. Occasionally these changes break the website especially if the changes never get tested. I would like to force everything to be funneled through the development branch, force it to get tested, and only then get it committed to the production version of the website. I don't expect that this will totally fix my problem but am hopeful that it would significantly decrease the amount of silly mistakes that make it to production.
I also don't want to insert an extra layer of complexity that is unneeded, thus my question about if this is even wise to do. Currently all the devs use sftp to push files so using git may be met with some resistance, but I really love the idea of versioning and rolling back to known good states should something slip past.
So I'm looking for advice on using git in this way or alternate methods of how others handle this scenario.