Git Automatically push to Dev and Production from

Question

I am somewhat new to Git only and I have only used it for basic projects with simple setups. Now I am struggling to wrap my head around a more complex setup. I have been up all night Googling but I can't find anything related to how I want to set this up.

I have three servers on my network: one for development (dev.example.com), one for production (www.example.com), and another that acts a central stage between the two (central.example.com).

I want to create a main (probably bare) Git repository on Central that I can push to from my local machine (which is separate from the three main servers but on the same network). Ideally, this repo would have two branches: master and Development. My local machine will only deal with this repo on Central.

When I push to the dev branch on Central, Central should then push those changes to the DEV server. Likewise, changes to the master branch should be pushed to WWW. I think using a commit/update hook would be the best way to accomplish this.

Here is a crudely drawn diagram:

 Local
   |
 Central
  /   \
DEV   WWW

Could someone kindly point me in the right direction? Thanks!

Answer 1

You can setup hooks in Git to easily get what you want here. Make use of post-receive hook, which receives the following from stdin:

<oldrev> <newrev> <refname>

Example:

aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master

Using the refname you can see in your script what branch is being pushed to and inturn push to the appropriate repo - www or dev.

Or, you can use the post-update hook which receives only refname and also as an argument to do the same thing.

For sake of completeness, the hook must be placed in the hooks of the Central repo.

Answer 2

You have to use post-update or post-receive hook; they are the ones that run after push to the repository completes. The only difference between them is how they get the arguments.

Than I'd suggest using an ssh trigger to the production/staging server tu run a pull from there, because:

• You need to run some code there anyway, because push in git does not support checking the pushed version out on the remote end. So you'd need another hook there.
• Running a push there means allowing push access there and that means one more thing to secure. On the other hand the ssh trigger will have hardcoded branch to pull, so nobody can do any harm with it unless the central repository is also compromised and more importantly, even if it is, potential harm is only limited to tricking it to pull bad version, but no data can be deleted an no access to the rest of the computer may be gained.

An ssh trigger is a script, that is associated with particular public key in ssh (prefix the public key in .ssh/authorized_keys with command=trigger). When you log in with ssh using that key, ssh will ignore command provided by client and run the trigger. This limits possible damage when somebody steals the key, because the trigger can use it's own logic to know what to do and not accept any input from the client.

Alternatively you can simply push and install appropriate hook to check out. See this question.