Merging two git repositories together with Django web server, one developer.

Question

Hi experts!

I started my Django project locally and have been using git just fine.

I got ahead of myself and copied the code to the server which instantly became out of sync with my local version. I hadn't done a branch or anything.

The two part question is what's the best structure for me to work locally, push/pull to test server and then update live server when test is solid, and how do I get it setup from where I'm at?

I've been developing with no branches in these early stages, but I'd like to instead follow standard practices for branching and merging.

I'm using NetBeans 6.8 locally for coding and I've also got GitX. So any integration tips would be helpful also but I'm comfortable doing whatever command lines are necessary.

Thanks!

James

Answer 1

First you should be able to have some form of communication between the git repositories you've got on your local machine, the test server and the live server. Git is very flexible in this regard so a few of the options are:

1. Have the test and live server pull from your local repository.
2. From development push to the test and live servers on appropriate times.
3. From development push to production and have the test server pull from production.
4. Have a fourth location where you'll store your git repo and push from development to that repository and have test and live pull from there.

Either way, once you reach a stage where you'll want to try something on the test server, create a tag. On the test server checkout that tag (git checkout <tagname>) and do your testing. (And once you are satisfied that it works the way you want, you can also use that tag on production. But I guess that's pretty obvious. :) )

The intermediate step, between creating the tag and checking it out, completely depends on your setup. Using the fourth option I just mentioned you'll need to push your tag first and fetch it on the testing machine. So the whole process would look similar to this.

<development>$ git tag v1.0
<development>$ git push
<development>$ git push --tags

<testing>$ git fetch --tags
<testing>$ git checkout v1.0

<live>$ git fetch --tags
<live>$ git checkout v1.0

Optionally you can (ab)use git decribe to check which tag you've got checked out at currently.

Regarding the branching and merging: what I like to do is create a branch for every feature I'm working on. Once I complete that feature I merge it back to master. So If I need to release before a feature is done, I can just leave that feature (and every releated) commit out of the release.

But this is just one way of doing it. You can setup the workflow to suit your situation. Especially regarding the use of branches. A more complex setup is described by Vincent Driessen in his article A successful Git branching model.

Disclaimer: I'm using git almost exclusively with one authoritative repo on a server (the fourth option). I haven't personally tried the other setups I suggested...

Update to respond to the comment by iJames:

To make dev push to and test pull from a new/different repository by default from now on, see the accepted answer of this question:

$ git branch --set-upstream master origin/master

With regards to the terminology:

• Push is relatively simple: it pushes your local commits to a different repository. See for instance the Git User's Manual.
• Fetching does the opposite, it "will update all of the remote-tracking branches to the latest version found in the repository". (Quote from the Git User's Manual.)
• The pull command not only fetches the changes in, but also merges them into the current branch. (See the example in the official Git tutorial.)