How to set up a git development environment when you're testing remotely

Question

This may seem like a silly question, but I feel like I understand GIT fairly well, and yet I can't seem to set up my development environment as I would like. I'm either missing something really simple, or I'm going about it all wrong :)

I initialized a bare git repo on my server, cloned it to my local machine, committed my files and pushed to origin. Then, locally I created three branches (master, release, develop) and published them all to origin. I intend to have multiple developers pulling from the develop branch, and I would like to make sure they can't push to the master branch but that may be better for a different question.

Now, I make my changes to the files locally, and then upload them to the testing server and check the testing server through the web browser. I would have to imagine that this is how most people test their work unless they have their computers configured as web servers and have php and mysql installed. Once I'm happy with my changes, I push them to the origin repo, and everything works fine.

My challenge comes in keeping the testing server in synch with my local machine. I've tried setting up a repo in my remote testing directory, and I've added a second remote to my local git repo, hoping I could push to the testing repo to synch the files on the testing server with my local files. But I can't figure out how to have two remotes and keep both of them in synch with my local machine.

If I create a new local branch, check it out to start working on a new feature and then push the branch to my testing remote, the head on the testing remote is still master and not my new feature branch. Therefore, i'm making changes locally to a feature branch, but when I publish the changes to the testing server through coda, I'm actually changing files on the master branch of the testing repo. If I can't keep my testing snapshots in synch with my local snapshots, I don't know how to take full advantage of gits branching features.

Is it really that crucial that I am developing AND testing locally? How on earth does one set up a development environment with git when you have to test remotely? Is having a testing repo the completely wrong way to think about this? There must be a way to have multiple remotes and have them checkout to the latest branch that is pushed so you can have an instance of your local files in synch remotely on a testing server. PLEASE HELP!

Answer 1

It's best to test locally. You can iterate faster that way. Fast iteration is extremely important. The time you spend on git pushes and remote connection latency add up, and will cost you more than setting up a complete local dev env.

Either way, at some point or another you will need to test your changes remotely as well. You can do that with a post-receive hook on your test server. Here's one way to do it.

On the test server:

1. Create a bare clone of your repo. Let's call this repo "testing".
2. Clone from testing, and set it up as the remote website you test in your browser
3. Create a post-receive hook in the testing repo that will update the website from the newly received branch

The post receive hook script:

#!/bin/sh
while read oldrev newrev refname
do
    upgrade_sh=./upgrade.sh
    if test -e $upgrade_sh; then
        upgrade_sh=$(readlink $upgrade_sh || echo $upgrade_sh)
        echo calling upgrade script: $upgrade_sh
        $upgrade_sh $refname
    else
        echo NOT calling non-existent upgrade script: $upgrade_sh
    fi
done

Put it in .git/hooks of testing, and make it executable.

I usually keep the upgrade.sh script inside my project under version control, and create a symlink to it from the hooks directory. The upgrade.sh main job of the upgrade script is to reset the deployment directory to the branch that you pushed:

#!/bin/sh -e
unset GIT_DIR
git checkout -f $1

In most cases you want to do more than this, for example on my Django websites I need to regenerate static content and signal restart to Apache.

I hope this will help you get started.