Gitflow

Gitflow is a branching model designed around the idea of isolating new development from finished, released work. It uses a set of well-defined branches, each with a clear responsibility, and a disciplined process for moving code between them.

The Branch Structure

Gitflow centres on two long-lived branches:

• main (sometimes called master) — contains only production-ready code. Every commit to main represents a release.
• develop — the integration branch where finished features land before they are released. It reflects the next state of the software.

Supporting branches are created as needed and deleted once their work is merged:

• Feature branches — branch off develop, deliver a single feature or change, and merge back into develop.
• Release branches — branch off develop when a release is being prepared. Bug fixes and version bumps happen here. They merge into both main and develop.
• Hotfix branches — branch off main when a critical bug needs an immediate fix in production. They merge back into both main and develop so that the fix is not lost.

How a Feature Flows Through

1. A developer creates a feature branch off develop.
2. Work happens on the feature branch — commits, reviews, iterations.
3. The feature branch is merged back into develop and deleted.
4. When the team is ready to release, a release branch is cut from develop.
5. Any last-minute fixes or version number changes go onto the release branch.
6. The release branch is merged into main (triggering a deploy) and into develop (so the fixes are not lost), then deleted.

Hotfixes

If a critical bug surfaces in production, a hotfix branch is created directly off main. The fix is tested, then merged into main — which triggers a deploy — and also into develop, so that the next release includes the correction.

Advantages

• main is always deployable. This is the cornerstone of the model. At any point, the code on main is safe to ship.
• Clear separation of concerns. Development, stabilisation, and production each have their own branch. This reduces the risk of an unfinished feature accidentally shipping.

Disadvantages

• Complexity. The model requires discipline to follow correctly. Forgetting to merge a hotfix into develop, or cutting a release branch at the wrong time, leads to subtle bugs that are hard to track down.
• Slower feedback loops. Code does not reach production until it passes through develop and then a release branch. Teams that deploy frequently find this cadence too slow.

GitLab Flow

A lighter variant that replaces release branches with environment branches such as staging and production. Code moves from main to staging (for testing) and then to production (for release). This simplifies the mental model but can lead to messy branch histories if the environment branches are not kept tidy.

GitHub Flow

The simplest member of this family. There is only one long-lived branch (main) and short-lived feature branches. A feature branch is created, worked on, reviewed via a pull request, and merged directly into main. Deployment happens off main whenever the team is ready.

GitHub Flow suits small teams shipping frequently. In larger teams with many concurrent features, merge conflicts become more frequent and the lack of a stabilisation branch can make coordinated releases difficult.