Gitflow

When I first started to learn to code, I only made git commits on the master branch, even when working with other people. I didn’t even really open pull requests. Github for me was a way of pushing and obtaining code from people I worked with, but there was no review of code except overwriting what someone else had done and pushing again to master. It seems ok and normal whenever your project isn’t released to any users yet.

When I worked on the Muzemaster project as a contractor, it was the first time I had to code on a branch called ‘develop’ and open pull requests to be reviewed by the original app builders. Looking at the repo now, these are my branch names:

  • messaging-fix
  • cms
  • notifications
  • timeout
  • next-router-update
  • messaging-fix

Some of these were extension features I added to the app, and some were bugs that needed fixed in production. These changes were deployed to a staging environment, and once tested, I would merge the develop branch into the master branch.

At my current company, Pingboard, we use a strategy called ‘Gitflow’ to name our different branches in order to keep our production and staging environments organized.

The main difference now is that I never create a new branch off of master. I always branch off of develop. My coworkers and I are constantly working on different features, and we name our branches accordingly such as feature/add-undo-button-in-org-chart or feature/send-weekly-out-of-office-email. When features are merged into develop, they are tested and packaged together in a release, which is merged into master with the release number, such as release/4.0.7.

If there is a bug in production that needs fixed immediately, a hotfix branch is created. These are named like hotfix/show-modal-on-ie11. A hotfix branch is tested locally and immediately merged into both develop and master.

This post by Atlassian explains it really well with examples. Check it out!

Published 12 Mar 2019

<%= @today.i_learned %> An early-career Web Developer's discoveries in Ruby, Rails, Javascript, and React. Currently the Support Engineer @ Pingboard in Austin, TX. I just write what I learn and try not to overthink things.
Kelsey Huse on Twitter