Git Branch Strategies

 

Overview

Ok so Git is such an instrumental tool in every day development. It gives us a safe environment to manage our codebase, it helps teams not step on each others toes when making changes, keeps a history of changes, and even lets us know who's responsible for what and when.

Using git isn't entirely straightforward though, and it helps to have a good well thought out strategy for your team from the get go. This article will describe the git-branch strategy we use for most of our projects here at Starleap, known as OneFlow. We have a single branch that lives forever as the master branch. In addition to master, we have numerous support branches. The rest of this document describes in greater detail the branches, different scenarios, and gives CLI examples.

The Main Branch

This is our master branch that lives forever. All code that makes it to production is eventually on this branch.

Feature Branch

This is where most day to day coding happens. This is used to develop new features and to fix bugs. Feature branches can be named as followed:

  • feat/<JIRA-ID>-<short title> — for branches that belong to a bigger epic, eg User Authentication, Bluetooth integration, In-App Chat etc
  • task/<JIRA-ID>-<short title> — for branches that take care of smaller changes that can be merged by PR into master or a feature branch eg Changing color of a particular text field from “Red” to “Blue"
  • bug/<JIRA-ID>-<short title> — for branches that fix bugs but don’t need to be released immediately eg a NPE on screen that is rarely viewed.

How to

To create a feature branch from mastergit checkout -b feature/SL-00-my-new-feature When feature is ready to be merged into master open a PR, click the merge button after approvals are gained, and delete the branch. If using CLI:

git checkout master
git merge --ff-only feat/SL-00-my-new-feature
git push origin master
git branch -d feat/SL-00-my-new-feature
git push origin :feat/SL-00-my-new-feature

Release Branch

This branch is used before we release to the Playstore. We first make a branch off of master to create a build to give to QA. As QA works with the build, any bugs that arises, we commit to the release branch so they can reevaluate. After QA approves the build, we tag the last commit on the release branch, make a production release build, merge into master, and delete the branch. Naming Convention: release/<release version>

How to

git checkout -b release/1.0.0
(Fix issues as they arise and continue to supply QA with builds each time this branch gets a commit)
(QA approves the build)
git tag 1.0.0
(Release a build to PlayStore)
git checkout master
git merge release/1.0.0
git push —tags origin master
git branch -d release/1.0.0
git branch push origin :release/1.0.0 (delete the branch remotely because it's been merged. Can use delete branch button on Github)

Hotfix Branch

If we make a release that has an urgent bug that needs a production fix ASAP, eg application crash on launch, you are in need of a hotfix branch. To create a hotfix branch we grab the commit of our last release, branch off, make our fix, get approval, and release to store. Aside from creating a hotfix branch, there are no differences than a release branch. Naming Convention: hotfix/<release version>

How to

git checkout -b hotfix/1.0.1
(Fix issues as they arise and continue to supply QA with builds each time this branch gets a commit)
(QA approves the build)
git tag 1.0.1
(Release a build to PlayStore)
git checkout master
git merge hotfix/1.0.1
git push —tags origin master
git branch -d hotfix/1.0.1
git branch push origin :hotfix/1.0.1 (delete the branch remotely because it's been merged)

Wrapping up

Git is awesome on it's own, but even better when everyone on the team is using it in consistency. Having a simple strategy and some good documentation to go back to (feel free to use this article) will help get the best out this vital tool.

The following are the main advantages of the OneFlow strategy.

  • Maintaining a single long-lived branch simplifies the versioning scheme.
  • Day-to-day operations that developers have to perform are also dramatically simplified.
  • Cleaner and more readable project history.

We also believe that both "OneFlow" and "GitFlow" are both very well suited for most software development projects, although we should point out that there is no silver bullet, so feel free to tweak this slightly or look into alternatives to suit your needs.

Happy coding!