Git: Creating a Hybrid Workflow: Merging Gitflow with Atlassian’s Branching Model

by Ralph Kleinschmidt

Acknowledging the contributions of Gitflow and Atlassian’s Branching Model, I've crafted a unified approach, combining the essence of both methodologies while employing pure Git commands.

Understanding the Git Flow

In the Git Flow workflow, collaboration among developers is facilitated through a central repository. Developers operate locally and push branches to the central repo for synchronization.

Divergent Branches

Unlike the traditional single-branch approach, Git Flow incorporates two primary branches to chronicle project history. The master branch maintains the official release history, while the develop branch acts as a staging area for feature integration. Tagging commits in the master branch with version numbers offers clarity in release management.

The workflow pivots around the usage and distinction of these two branches.

Feature Branches

Every new feature resides in its dedicated branch, allowing for seamless collaboration and backup. Rather than branching from master, feature branches stem from develop. Upon completion, features are merged back into develop, refraining from direct interaction with master.

Key Guidelines:

  • Base branch: develop
  • Merge target: develop
  • Naming convention: Avoid master, develop, release-, or hotfix-

Release Branches

When the develop branch accumulates adequate features for a release or nears a predetermined deadline, a release branch branches off from develop. This initiates the release cycle, permitting only bug fixes, documentation updates, and release-oriented tasks within this branch.

Once ready for deployment, the release merges into master, accompanied by version tagging. Additionally, integration with develop ensures alignment with ongoing developments.

The segregation of release preparation facilitates concurrent polishing of the current release while development progresses for subsequent releases, delineating clear development phases within the repository.

Key Guidelines:

  • Base branch: develop
  • Merge targets: develop and master
  • Version increment: Major or minor
  • Naming convention: release-* or release/*

Bug Fixing and Maintenance Branches

For expedited patching of production releases, maintenance or hotfix branches are employed. These branches directly branch off from master, facilitating swift bug resolution. Upon fixing, merging into both master and develop ensures comprehensive integration.

The dedicated maintenance line allows issue resolution without disrupting regular workflow or awaiting the next release cycle, akin to ad hoc release branches working in tandem with master.

Key Guidelines:

  • Base branch: master
  • Merge targets: master and develop
  • Version increment: Patch
  • Naming convention: hotfix-* or hotfix/*

Example

Let’s explore a simplified release cycle management scenario within this workflow assuming the central repository has been established.

Create A Develop Branch

Begin by supplementing the default master with a develop branch. One developer creates an empty develop branch locally and pushes it to the server:

git branch develop
git push -u origin develop

This establishes a comprehensive project history in the develop branch, while developers clone the central repository and set up local tracking branches for develop.

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

With this setup, all participants have synchronized historical branches.

Two Developers Begin New Features

Suppose developers Mary and John kickstart independent feature developments. They create separate branches for their features based on develop:

git checkout -b some-feature develop

# Optionally, push branch to origin:
git push -u origin some-feature

Both developers contribute to their feature branches through standard Git procedures: edit, stage, commit.

git status
git add some-file
git commit

Mary Concludes Her Feature

Upon completing her feature, Mary creates a pull request and askes for her feature to be merged into develop.

git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop

git branch -d some-feature

# If you pushed branch to origin:
git push origin --delete some-feature

The first command makes sure the develop branch is up to date before trying to merge in the feature. Note the avoidance of direct merges into master.

Mary Begins To Prepare A Release

While John continues his feature development, Mary begins preparing the initial project release. She creates a dedicated release branch encapsulating the release tasks, establishing the release version, following the SemVer recommendation of V0.1.0:

git checkout -b release-0.1.0 develop

# Optional: Version bump, commit
# Release preparation, commit

This branch serves as a staging ground for polishing the release, accommodating tasks like testing, documentation updates, and readiness assessments.

Mary Finalizes the Release

Upon completing the release preparations, Mary merges the release into both master and develop, thereafter deleting the release branch. Integration with develop ensures accessibility to recent updates for ongoing feature developments.

git checkout master
git merge --no-ff release-0.1.0
git push

git checkout develop
git merge --no-ff release-0.1.0
git push

git branch -d release-0.1.0

# If you pushed branch to origin:
git push origin --delete release-0.1.0

Release branches serve as intermediaries between feature development and public releases, warranting version tagging for easy reference.

git tag -a v0.1.0 master
git push --tags

Addressing Bugs and Maintenance

Following the release, Mary resumes feature development until a user reports a bug. To address it, she creates a maintenance branch from master, fixes the bug, and integrates it back into both master and develop.

git checkout -b hotfix-0.1.1 master

# Optional: Version bump, commit
# Bug fixing, commit

git checkout master
git merge --no-ff hotfix-0.1.1
git push

Integration with develop ensures consistency across ongoing developments before the branch is deleted.

git checkout develop
git merge --no-ff hotfix-0.1.1
git push

git branch -d hotfix-0.1.1

Finally, tagging the master commit signifies the patch release.

git tag -a v0.1.1 master
git push --tags

Embrace the Flow!!

Incorporating elements from Gitflow and Atlassian’s Branching Model, this unified workflow streamlines collaboration and release management within Git repositories, enabling efficient development cycles and smoother project deliveries.