2

This question is really on branching, and merging. I just got turn on to git last week and I really like it but I have some questions.. everything I read tells me never to work in the master branch. So before I make any programming changes I make a new branch and do my work and then I merge in back into the master... I don't know if this is right so I would like to hear from others.

But how do I handled code going to staging, and production? Do I just tag code in the master or do I make a production branch for each releases.

Please can someone please tell me how to you handled working with code moving to staging, testing and production... Do you use tags or branches or both.

techsjs2013
  • 2,607
  • 5
  • 20
  • 25

2 Answers2

4

There are plenty of models out there: Your version control setup can be as simple or as complicated as you need it to be. Here's one popular methodology: http://nvie.com/posts/a-successful-git-branching-model/

Personally I use a new branch for each feature/bug, then merge into master like you have been doing. Then simply tag for production releases with staging servers running off master.

If you need something more complicated, you can do something like the aforementioned Git Flow technique, which has release branches etc. but if you don't need it, then you don't have to do it.

ChrisC
  • 2,461
  • 1
  • 16
  • 25
  • Thannks ChirsC but can I ask you about releases to productions and roll backs. After you merge into master do you put a tag on the code for production? if so how do you tag, pull off based on tag etc – techsjs2013 Feb 10 '13 at 15:01
  • I wouldn't tag as soon as I merged back to master, just when I was ready to do a release. e.g. If I was working on 2 features, each in its own branch and I wanted to release after both were completed, I would complete feature 1, merge to master, then complete feature 2 and merge that to master, then tag. See http://git-scm.com/book/en/Git-Basics-Tagging for info on tagging: I'd usually create an annotated tag, git push the tag to the repo (e.g. GitHub), then git fetch and git checkout tag on the production server. Alternatively you could have the production server as a remote and push to it. – ChrisC Feb 10 '13 at 15:10
0

Don't forget the other dimension of a distributed version control system:

You don't have just tagging and branching, with a workflow of merges to manage the promotion of your code along the release management process, you also have the orthogonal feature of publication (push/pull across repositories)

So nothing prevents you to push a certain tag (from any branch you want) to a dedicated UAT, SIT or pre-prod repo in order to make your tests, before releasing it into production.
Note that the production aspect can very well exclude git from its process, in order to keep only what is needed to run and monitor the app, reserving git for the application development life cycle. See "Using git below web root in production".

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250