GitLab Flow

GitHub Flow plus environment branches (staging, production) or release branches, with an "upstream first" rule.

Context

Teams that want the simplicity of GitHub Flow but need to promote changes through environments (staging, pre-production, production) or maintain stable versions of a product.

Solution

Starts from main and adds branches as needed. Two variants:

1. Environment branches (continuous delivery with approvals):

feature ──▶ main ──▶ staging ──▶ production

Code is only promoted rightwards (merge main into staging, and staging into production).

2. Release branches (versioned software):

main ──●──●──●──●──▶
          \     \
           2-3-stable   2-4-stable   ← fixes land in main and are cherry-picked

Key rule: upstream first. A fix is always made in main first and only then brought to the environment or release branches. That way no bug is fixed in just one branch.

#When it fits

  • There is a staging environment with manual validation or mandatory approval (compliance).
  • You cannot deploy to production every time something merges into main.
  • You support some parallel versions, but not enough to need full GitFlow.
When NOT to use it
  • If you deploy straight from main to production: GitHub Flow is enough.
  • Environment branches can turn into a "manual pipeline": if every promotion is a hand-made merge, automate it.
Tradeoffs
Pro Con
Supports environments and explicit approvals More branches than GitHub Flow
Simpler than GitFlow Manual promotion between environments slows the flow
"Upstream first" prevents regressions Requires discipline with cherry-picks

#git #branching #gitlab #environments