Git Branch Types and Continuous Integration Branch Strategies

When managing branches, teams often face challenges such as starting a feature without affecting others, keeping many branches organized, knowing which branches have been merged, handling releases while allowing ongoing development, and quickly fixing production bugs.

A robust continuous delivery system requires a suitable branching strategy. Below are the common branch types and how they fit into continuous integration.

1. Common Branch Types

Master (main) branch : The sole branch that holds the official, production‑ready releases. It is created automatically when the repository is initialized.

Develop branch : Used for daily development and nightly builds. When a release is ready, develop is merged into master.

# git checkout -b develop master

# git checkout master

# git merge --no-ff develop

The --no-ff flag forces a merge commit so the history of the release remains clear.

Temporary branches (created from develop or master and deleted after use):

Feature branch – for a specific feature, named feature-* . Created from develop and merged back into develop.

Release branch – for pre‑release testing, named release-* . Created from develop, merged into both master and develop, and tagged.

Hotfix (fixbug) branch – for urgent production bug fixes, named fixbug-* . Created from master, merged back into master and develop, and tagged.

Example commands:

# git checkout -b feature-x develop

# git checkout develop

# git merge --no-ff feature-x

# git branch -d feature-x

# git checkout -b release-1.2 develop

# git checkout master

# git merge --no-ff release-1.2

# git tag -a 1.2

# git checkout develop

# git merge --no-ff release-1.2

# git branch -d release-1.2

# git checkout -b fixbug-0.1 master

# git checkout master

# git merge --no-ff fixbug-0.1

# git tag -a 0.1.1

# git checkout develop

# git merge --no-ff fixbug-0.1

# git branch -d fixbug-0.1

2. Branch Strategy Classifications

The three high‑level strategies are:

Mainline development, branch releases – All development goes to the mainline; a release branch is cut when needed.

Branch development, mainline releases – Features are developed in separate branches and merged back to the mainline before release.

Mainline development, mainline releases – Only a single branch exists; every commit must be production‑ready, requiring strict code review and automated testing.

Each has trade‑offs; the article recommends a hybrid of “mainline development, branch releases + feature branches”.

3. Popular Workflows

Git Flow : Uses long‑living master , develop , release , feature , and hotfix branches. New features are built on develop , releases are cut to release , and hotfixes go directly to master and develop . Considered complex.

GitHub Flow : Only master and short‑lived feature branches exist. All changes go through a feature branch, code review, and merge into master , which is always deployable. Simple but relies on strong automation.

GitLab Flow : A family of three models – with a production branch, with environment branches, or with version branches – each suited to different release cadence needs.

4. Choosing the Right Model

Factors to consider include team size, need for parallel development, release frequency, and automation support. For most scenarios, a “branch development, mainline release” approach (feature branches + release branches) offers a good balance of flexibility and integration speed, aligning well with DevOps practices.

Key principles for successful adoption:

Share a single mainline branch.

Keep feature branches small and short‑lived (ideally < 2 weeks).

Use consistent naming conventions (e.g., feature-* , release-* , fixbug-* ).

Ensure all changes for a feature reside in one branch to maintain atomic commits.