Git workflow/Deployment

Question

I'm new to Git and trying to move my website away from SVN to GIT for version control and also deployment.

I've got a number of developers who will work on their local machine and I've got 3 servers, 'development', 'staging' and 'production'.

I've been reading books and watching videos of how Git works so I think I'm pretty familiar with it now as in adding, committing etc, however I need advice on the workflow and deployment.

The first thing I need to know is where to initialize the GIT repository. Does it need to be on the 'production' server and then I clone it on 'staging' and 'development' and each developer also clones it to their local machine?

Secondly, should each server have it's own branch? Ie 'development' will have a 'development' branch, 'staging' will have a 'staging' branch and 'production' will have a 'production' branch?

Thanks

Answer 1

I recently moved my team from SVN to Git too and we have the same setup of 3 servers, prod, stg and dev..

For the migration process , first sudo apt-get install git-svn and then..

$ git svn clone [subversion_repository_url] /path/to/git/repository
$ cd /path/to/git/repository
$ git remote add origin [gir_repo_url]
$ git push origin master

For Workflow ,

This link titled " A successful Git branching model " was immensely useful. It entails how to go about using a 'Production - Staging - Dev ' type of workflow for a team.

With regards to Deployment :

On each of the servers, what we do is, Each of the servers have the git repo someplace on the filesystem. To deploy, I archive the respective branch I need to deploy and unzip it into the /srv/www/ folder..

For example, on Prod , to deploy the master branch ,

sudo git archive --format zip --output output.zip master -0

^The 'master' indicates the branch you want zipped up. This excludes the .git folder. And then to unzip inside the /srv/www/ folder, sudo unzip output.zip -d /srv/www/app/ This is the equivalent of an svn export command.

For the Staging server we usually checkout one of the Release branches or the Dev branches ..

And for the Dev server , we checkout whichever feature-branch we need to perform testing on.

Answer 2

You've got 3 questions here: how to deploy, how to structure branches, and how to structure/host repositories.

How do I structure branches?

You could start simple. You've already got an SVN repository, so if you've got a trunk and branches, you could set those up the same way in git. If that doesn't work for you, change it only when you find the need.

If you want something more advanced, look at git flow . Another good workflow is the one that github uses . It's designed to be simpler than git flow.

How do I host the repository?

One easy way would be to do just as you're doing with SVN. Have a central repository on a central server. Everybody pushes and pulls to and from that central server. Another option would be to give some sort of lead developer the "official" repository, where that lead would pull other changes from the contributing developers as they meet the lead's approval. There are a number of ways you could do this. You'd just have to decide what works best for you.

How do I deploy?

Again, this doesn't need to change from your SVN workflow either. You're probably doing an svn update from each box. I'd just do a git pull to each box and keep everything else much the same.

Answer 3

A lot of it does depend on what ends up being right for you.

The branching model linked in another answer here is a very good starting point.

Generally, you'll have a master branch which represents the released code.

Staging depends on what you want to stage - our team has a separate branch called staging which is used by the continuous integration server's staging build. Different features can be merged into this branch to test them on staging.

Deployment will depend on whether you use CI or deploy directly from a branch in the repo.

Answer 4

I've developed my own strategy. It was originally based off of nvie's:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

It allows ad hoc mix and match of completed features. The cornerstone of this strategy is to start each feature from the same place in history per iteration.