GitFlow overview and workflow

A structured git branching model that empowers team members to have more control over their releases and feature work and creates a more stable code base.

The main branches

There are two branches that live forever:

  • master

  • develop

Master is the same branch everyone is familiar with and its the "main" branch that reflects production ready state. Develop is the branch that reflects the latest changes. It could also be considered your nightly branch since automatic nightly builds could come out of here.

Supporting branches

There are three types of supporting branches for GitFlow:

  • Feature branches

  • Release branches

  • Hotfix branches

These each server a purpose, but at the end of the day they are just Git branches.

Feature branch

Branches off of:

   develop

Merges back into

   develop

Branch naming convention:

   feature/TICKET. e.g feature/BLAH-1234 or feature/flinehan/BLAH-123

This is the core of GitFlow and used to develop new features for the upcoming release.

Release branches

Branches off of:

   develop

Merges back into

   develop and master

Release branches are all of the features that have been merged into develop up until this point. Or release can be a cherry picked version of develop. These branches also allow for any last minute changes, minor bug fixes, and meta release changes. When develop hits the point of "release ready" thats when you cut a release branch.

Hotfix branches

Branches off of:

   develop

Merges back into

   develop and master

Something broke in master and it needs to be fixed, time to create a hotfix. Similar to release branches they are used to prepare for a production release. This enables team members to continue work on the develop branch, while a dev can easily create a hot fix for production.

Typical workflow

This assumes you have the git flow command line tools installed. These tools aren't required but it streamlines most of the work flow for you.

//Init the repo for HubFlow tools - this only needs to be done once.
git hf init
//You grabbed a ticket and want to start work
git hf feature start TICKET-1234 //feature name TICKET-1234
//once your work is ready create a PR against develop. Then when that is merged:
git hf feature finish TICKET-1234 //feature name
//develop is now all ready for a new release
git hf release start x.x.x //version MAJOR or MINOR follows semver
//create a PR of the release branch against master. Once that is merged into master
git hf release finish x.x.x //version
//it will ask you for a comment and a tag.
//oh no. your release to master had a bug. No worries create a hot fix branch.
git hf hotfix start x.x.x //version PATCH follows semver
//create a PR agains master once that is merged then you run
git hf hotfix finish x.x.x //version

The final thing to keep in mind is tools should empower teams to get things done. If GitFlow using the hubflow tooling doesn’t enabled teams to get things done, then find another process/tool/strategy that works for the team!

Previous
Previous

Thoughts on testing

Next
Next

Should the future of UI be micro?