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 git.
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:
I tend to borrow the gitflow naming conventions for the workflow:
- feature - Feature that is being worked on. eg. feature/newletter-signup
- hotfix - Hotfix is for when something is broken in production. eg. hotfix/cant-login
- support - Support issues reported be customers or other team members. eg. support/footer-misaligned
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.
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 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.
In the next article I will go over the actual day to day workflow using the above branching model.