PrismitaLEARN · PRACTICE · GROW

What Git branching strategies do you know (GitFlow, trunk-based, GitHub Flow)?

Git & SDLC Branching Intermediate 2–3 Yrs3–5 Yrs Architecture 1 min read

Quick Answer

GitFlow — long-lived develop + main, plus feature/, release/, hotfix/ branches; heavy, suited to versioned/on-prem releases. GitHub Flow — one main, short-lived feature branches, PR, deploy from main; simple, fits continuous delivery. Trunk-based — everyone commits to main (behind feature flags) with very short branches; maximises integration frequency.

GitFlow has a permanent develop and main, with feature, release and hotfix branches off them — it's structured but heavy, and it makes sense when you're shipping versioned software that customers install. GitHub Flow is much simpler: one main, you branch off it for a feature, open a PR, and deploy from main. Trunk-based takes it further — everyone integrates into main constantly, with incomplete work hidden behind feature flags. The industry has moved toward the trunk-based end because long-lived branches lead to giant, conflict-ridden merges and delay finding integration bugs.

  • The trend is toward trunk-based / GitHub Flow because long-lived branches cause big, painful merges and delay integration.
  • Feature flags let you merge incomplete work to main safely, decoupling deploy from release.
  • GitFlow still makes sense when you support multiple released versions in parallel.
  • Whatever the model: keep branches short, merge often, protect main with required checks.
All Git & SDLC questions More on Branching