Skip to content

Git Branching Strategy for CareLink and MLife

Branching Strategy

In modern software development, speed and agility are crucial when it comes to developing and releasing software. However, when you have a large team of developers working simultaneously, branching and merging code can become complex to manage.

Therefore, teams need to have a process in place to implement changes. A branching strategy, therefore, is the strategy that software development teams adopt when writing, merging and deploying code when using a version control system.

It is essentially a set of rules that developers can follow to stipulate how they interact with a shared codebase. This is where having an efficient branching strategy becomes a priority for these teams.

A Branching Strategy aim to: * Enhance productivity by ensuring proper coordination among developers * Enable parallel development * Help organize a series of planned, structured releases * Map a clear path when making changes to software through to production * Maintain a bug-free code where developers can quickly fix issues and get these changes back to production without disrupting the development workflow

For CareLink and MLife products, we've been leveraging Gitflow model.

Gitflow Overview

Gitflow is a git branching model that involves the use of feature branches (or shot-lived branches) and multiple primary branches

Develop and main branches

Instead of a single main branch, this workflow uses two branches to record the history of the project. The main branch stores the official release history, and the develop branch serves as an integration branch for features. It's also convenient to tag all commits in the main branch with a version number.

This branching strategy consists of the following branches:

  • Main - The main branch stores the official release history.
  • Develop - The develop branch serves as an integration branch for features.
  • Feature - The feature branch is to develop new features. The feature branch is created off the develop branch.
  • Release - The release branch help prepare a new production release. Its branched from the develop branch and must be merged back to both develop and main.
  • Hotfix - The hotfix branch helps prepare for a release. But unlike release branches, hotfix branches arise from a bug that has been discovered and must be resolved.

Feature branches

Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off of main, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with main. These branches should be very short-lived.

For CareLink or MLife development the feature branch should exists for 1 day to maximum 1 sprint. In ideal scenario we should be merging feature branch to develop as short time frame as possible. After the story is closed branch should be merged and deleted. Before the sprint is closed, feature branch should be merged to develop

Release branches

Once develop has acquired enough features for a release (or a predetermined release date is approaching), we create a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Whenever a bug is fixed in release branch it should be merged back to develop branch immediately. Ideally every user story for a release branch should have a task to sync the changes back to develop.

When the release is finished, the release branch is merged into main and into develop too, to make sure that any changes made in the release branch aren’t accidentally lost by new development activity.

  • After release is done, release branch needs to be merged to main. it should be tagged with official release number.
  • After release is done, we should validate all changes from release are sync with develop.
  • Lock the release branch and make sure no changes are pushed to release branch.
  • Release branch should be deleted or kept for some time based on auditing requirements.

The main branch tracks released code only. The only commits to main are merges from release branches and hotfix branches.

Hotfix branches

Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they're based on main instead of develop. This is the only branch that should fork directly off of main. As soon as the fix is complete, it should be merged into both main and develop (or the current release branch), and main should be tagged with an updated version number.

Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle. You can think of maintenance branches as ad hoc release branches that work directly with main.