Git branch based workflow

- 2 mins

Git Branch Based Workflow

I’ve tried really hard to understand svn back in the day, but just could never get it. Don’t know why. Maybe my brain is not wired the right way.

When I learnt about this new source control system with a weird name git and it was from (the father of linux) Linus Torvalds I thought it would be even more complex so stayed away from it for about a year.

During this year in the source wilderness, I kept hearing more and more about git and how great it is with ever increasing intensity. So eventually I decided to give it a go.

I was hooked from day one. I :heart: git.

Branching model

We use a very simple branching model to keep track of what code goes where:

Let us discuss what each branch does in more detail:

Feature/Hotfix/Support

I tend to borrow the gitflow naming conventions for the workflow:

Staging

This branch is deployed to the staging environment so that it can be tested by the Quality Assurance team and then release to client for review.

Production

This is the master branch for the project. As you can tell from the name, this branch contains the code that is deployed to production and end users see day to day.

Git in the Cloud

As a service provider for hosted git repositories I’m using Gitlab for all repositories with all Open Source projects also pushed to Github.

Summary

As you can see, this is a super bare/simple setup. I’ve played around with git-flow and other methodologies but they all turned out to be overkill for our needs.

In the end, the simpler something is, the less there is room for error to creep in. It also make it super simple to teach to someone.

Next up

In the next article I will go over the actual day to day workflow using the above branching model.

Sergei Filippov

Sergei Filippov

Web, development, family & life.

rss facebook twitter github youtube mail instagram linkedin google