Integrity Git Workflow — A Lightweight Adjustment to GitFlow

A middle-ground branching model used at Integrity that blends GitFlow structure with GitHub Flow speed.

There are a few popular branching models for small teams. GitFlow can bury newcomers under boxes and arrows, while GitHub Flow can feel too minimal when several engineers collaborate on the same feature. After trying both, Integrity settled on a middle path that keeps deployments fast and history readable.

When we compared options, each had shortcomings:

GitFlow felt heavy. We practise continuous deployment and sometimes ship several times a day, so a release-branch model slowed us down.
GitHub Flow didn’t cover cases where multiple engineers share the same feature.

The Simplified Flow (Integrity Style)


o----------------------o----------------o------------o-----------------o---> MAIN
 \                    /                  \----------/ \ HOTFIX        / 
  \                  /                                 \             /
   ----------------------------o---------------------o--o--------------> DEVELOP
                                 \                  /
                                  \----------------/ FEATURE

Principles

main is always deployable.
develop is always ready to deploy.
We can ship multiple times a day, but we deploy whenever it makes sense.
Only develop or a hotfix/* branch merges into main. Pull requests should not target main directly.
Short-lived branches use prefixes feature/, fix/, or chore/ and merge back to develop frequently, hiding incomplete work behind feature flags when needed.
Long-lived feature branches are still possible (e.g., wide schema changes) but discouraged.

1. A Normal Change (feature/lasers)

Cut feature/lasers from develop.
Commit small, reviewable chunks; open a PR to develop.
Re-sync with develop as needed (merge, not rebase) to keep history simple.
After approval, merge — preserve the merge commit so the log shows when the feature landed.
The next person deploying develop can skim the merge commits and know exactly what will ship.

2. A Hotfix (hotfix/temperature-crash)

If prod is on fire and we can’t quckly do a normal change This could be due to development in a unintenionaly broken state or a thorough client QA process. Hotfixes should be avoided if possible.

Branch hotfix/temperature-crash from main.
Make the fix, get a quick review.
Merge back to main (merge commit records the hotfix) and immediately merge main back into develop so future work isn’t missing the patch.

3. A Long-Lived Feature Branch (feature/big-lasers)

Sometimes several engineers need weeks on a feature that can’t be flag-gated easily.

Create feature/big-lasers from develop.
Each engineer branches feature/blue-lasers and feature/red-lasers off that root.
Those sub-branches PR back into feature/lasers.
Periodically merge develop → feature/lasers to stay fresh.
When finished, merge feature/lasers back into develop.

Benefits

Fewer risky deploys — work lands in develop continuously, but we decide when to push to main.
No deploy babysitting — engineers aren’t forced to ship multiple times a day, but the option is there.
Clean history — merge commits appear only when they mean something (feature → develop, develop → main, hotfix → main).
Simple mental model — one long-lived integration branch (develop) plus short branches for features and emergencies.

For a small team that values speed and clarity, this flow has served us well. It can be adjusted to fit your projects needs. For example internal projects may only have main and not develop and large projects may have additional steps required.