Flow

A single developer can work on a single develop branch to produce a well-versioned codebase.

Falling back to PNG as your browser does not support SVG.

Download SVG | PNG

Feature branching

Once there are multiple developers involved, the develop branch takes on a new function. It’s always in a working state, i.e. when feature branches are merged back in, the full set of integration tests pass.

Falling back to PNG as your browser does not support SVG.

Download SVG | PNG

Multiple independent features can be developed in parallel, by appropriate subsets of the team, such that their work doesn’t interfere with each other.

Falling back to PNG as your browser does not support SVG.

Download SVG | PNG

Features under epics

Where features overlap with each other, they can sit under epics. Each epic may have multiple component feature branches. The epic as a whole gets merged back into develop when meaningful to do so. If it’s working, perhaps feature-toggled, it does not necessarily have to be complete.

Falling back to PNG as your browser does not support SVG.

Download SVG | PNG

Releases

Eventually it’s not viable to just deploy directly from develop, so we create dedicated release branches.

Falling back to PNG as your browser does not support SVG.

Download SVG | PNG

Those release branches are periodically and systematically deployed to live. Often the master branch is used for sending code to production. Individual commits can be tagged with a release version number.

Release branches tend to be ephemeral: they exist for as long as they’re in service (or recently in service), then get archived off or deleted. Once deleted, the code they released will still be available as a tagged commit in master.

Falling back to PNG as your browser does not support SVG.

Download SVG | PNG

Hotfixing

When something goes wrong the master branch can be rolled back, or fixed forward. In most situations, time allowing, a release can be patched and flushed through, but occasionally something quicker is required.

Falling back to PNG as your browser does not support SVG.

Download SVG | PNG

Where hotfixes are created, the challenge is ensuring that the rest of the codebase gets that code, so that master does not diverge from develop. Once the hotfix changes have made it back into develop, they will inherently become part of every new release, but old/active releases that have yet to be deprecated may need the hotfix merging in manually to ensure the pre-deployment tests are representative of live.

Falling back to PNG as your browser does not support SVG.

Download SVG | PNG

Release patching

Where patches are created against a release, rather than master/live, their code too needs to be merged back into develop.

Falling back to PNG as your browser does not support SVG.

Download SVG | PNG

GitFlow

Ultimately, the completely picture looks complicated, but is just based on a series of logical steps that make it surprisingly easy to follow so long as rare events (like hotfixes or patches) are done with rigorously.

Falling back to PNG as your browser does not support SVG.

Download SVG | PNG

Help

If you’d like help moving your team onto GitFlow, please get in touch.

Leave a comment