GitFlow basics

GitFlow uses long-lived branches with defined roles:

| Branch | Role | |--------|------| | `main` | Production-ready history | | `develop` | Integration branch for next release | | `feature/*` | Branch from develop, merge back | | `release/*` | Stabilize before production | | `hotfix/*` | Emergency fix from main |

It can fit scheduled releases and multiple supported versions, but many web teams find the overhead heavy when deploying continuously from main.

On interviews: name branch roles, then evaluate fit for release cadence, team size, and rollback — not popularity.

Common pitfalls: GitFlow by default on a team that ships daily; duplicate merges between develop and release; develop drifting far from main.

The trade-off is structured release lanes versus simplicity of trunk-based flows.

Checklist:

• Know main, develop, release, hotfix roles.
• Adopt only when release cadence warrants it.
• Compare with trunk-based and feature flags.
• Avoid ceremony without operational benefit.