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.

  • Use something like jenkins to perform automated testing and then take it a step further, and let jenkins be the only way to get code pushed to prod, which only happens if tests pass. – EEAA Aug 9 '14 at 3:48

As @EEAA mentioned in a comment, you almost certainly want a CI/CD system, not a chain of git repos. I've most recently been investigating go.cd, and it has nice support for the kind of "approval-based" deployments you're describing, via a web interface rather than needing people to pull/push code around.

I'm a strong believer (as someone who does technical management) in the idea that a manager should trust their devs not to do stupid things, and if the devs do stupid things, the manager is at fault -- either because the appropriate expectations haven't been put in place, or because the wrong people were hired. If the devs are pushing broken code live, the manager needs to work out why the devs are doing that, and solve that problem, not block devs from being able to push code live.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.