Mastering Gitflow: A Step‑by‑Step Guide to Structured Git Branching

When adopting Git in a workplace, many workflows exist; Gitflow is a popular model that defines a strict branch structure around releases.

How Gitflow Works

It uses a central repository; developers work locally and push branches. The key difference is the branch layout.

Branches for History

Two permanent branches: master holds official release history, develop integrates ongoing features. Tags are applied on master.

Feature Development Branches

Each new feature gets its own branch created from develop; after completion it is merged back into develop, never directly into master.

Release Branches

When develop has enough features or a release date approaches, a release branch is created from develop. It is used for final testing, documentation, and bug fixes. The branch is eventually merged into both master (with a tag) and develop.

Maintenance (Hotfix) Branches

Critical bugs after a release are fixed on a branch created from master. The fix is merged into master (tagged) and also back into develop.

Step‑by‑Step Example

Assume a central repository already exists.

Create develop branch

git branch develop
git push -u origin develop

Developers create feature branches

git checkout -b feature1 develop
# edit, stage, commit
git status
git add <some-file>
git commit
git checkout develop
git merge feature1
git push

Prepare a release git checkout -b release-0.1 develop Finish the release

git checkout master
git merge release-0.1
git tag -a 0.1 -m "Initial public release"
git push --tags
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

Hotfix a bug

git checkout -b issue-001 master
# fix bug, commit
git checkout master
git merge issue-001
git tag -a 0.1.1 -m "Bug fix"
git push --tags
git checkout develop
git merge issue-001
git push
git branch -d issue-001

Hooks can be configured on the server to trigger automated builds when tags or master are pushed.