Branching Strategy

BISS Branching Strategy

Branching strategy points to activites a project team should execute for integration, deployment and even delivery. In this part we will explain what we use for branching on daily basis and briefly touch on several branching strategy.

BISS Flow

This is the first workflow attempt that addresses multiple teams way of working. It’s not done by any means and should improve over time.

BISS flow

Let’s look at the usage of each branch:

  • Production(purple) : This branch should point to production ready state of your software. Any merge request to production branch should result with a deployment to your prod environment
  • Master(red) : Integration point for feature branches. Feature branches should split and merge back here. Tagging should be done in master branch, do not need to tag when a feature branch is merged but there should be a tagging policy.
  • Feature(green) : Contains any improvement that will face customer/user soon.

Few more points:

  • Since dev branch serves mostly as melting pot and master branch is already doing that, we decided not to use in BISS flow.
  • Feature branch names should be brief but comprehensive and seperated with hyphen
  • We should use rebasing when updating feature branches from master
  • Testing should be done before merging back into master
  • If supporting more than one version is necessary, different branches might be used to reflect those versions (Up until now we (here in BISS) haven’t maintain more than one version of a software. Since this scenario is not clear yet, it would be too vague and impractical to put into BISS flow)

Other Branching Strategies

Git Flow

This is the oldest approach that aims to solve integration problem. It has permanent master and develop branches and feature, release, hotfix branches that live limited amount of time. Releasing the software is the main goal and branches are created with this idea in mind. Depending on the circumstances, temporary branches might merge into master and/or develop branches.

Let’s briefly touch each branch:

  • Master: Reflects what is alive at production
  • Develop: Melting pot for feature branches
  • Feature: Concentrates on a new feature
  • Release: Provides room for release preparation
  • Hotfix: Aims to solve unexpected problems at production

It has too many braches to think of, requires mostly manual steps to manage and demands git CLI knowledge.

GitHub Flow

This is the much simpler form of git flow. Instead of losing the momentum while playing branches it puts emphasize on deploying more often. Master branch should be in such a state that is deployable at any time. Apart from a permanent master branch, there are temporary feature branches that brings new feature or bug/security fixes into being.

It can be explained as below:

  • Master branch should be reliable, don’t break its integrity
  • Feature branches should have descriptive names, it should give the idea at first glance
  • Push to remote server as much as possible, since everyone works at their own branch you cannot break anything
  • Use pull requests for code review
  • Merge(not rebase) after pull request is accepted
  • Deploy frequently

Gitlab Flow

Gitlab flow is not so much different than GitHub flow in essence. It also utilizes permanent master and short-lived feature branches and offers merging feature branches back into master often. There are few points that make Gitlab flow different than git flow as well.

On top of what GitHub flow says, Gitlab flow offers few additional branches for different needs:

  • Production branch: If deployment is not possible at a time, we can create a branch that reflects what should be in production environment. So team can continue working with master branch
  • Environment branches: If there are other environments other than production, such as staging and pre-production, we can employ new branches with corresponding name to reflect those environments
  • Release branches: If releasing(not deploying) is the need, then we can utilize release branches. Let’s say a bug fix is cruical, we should first try to merge into master and then cherry-pick into release branch. So that it doesn’t occur again and again

In order to prevent not needed merge commits, it offers rebasing when updating a branch from master, but when merging back into master branch opt for merging.

Since master branch is accepted as reliable, Gitlab flow promotes testing before merging back into master.