VocalHyre
Sign up

CI/CD · Ship safely, repeatedly

How do you choose a version control branching strategy?

Mediumbranchinggitrelease managementUpdated Oct 2026
Quiz this track

Short answer

Choose branching based on release cadence, team size and how much parallel work must be isolated. Trunk-based development suits frequent delivery, while release branches help when multiple versions must be supported.

A branching strategy is a coordination mechanism, not a moral choice. The more isolation you add, the more merge risk and integration delay you accept in exchange for parallel work and controlled releases.

  • Trunk-based: short-lived branches merged to main daily, supported by feature flags and strong tests
  • GitHub flow: a simple main branch plus short feature branches and pull requests
  • GitFlow: long-lived develop and release branches, useful for scheduled versions but heavy for continuous delivery
  • Release branches: cut from main when a version must be maintained while main moves on
  • Hotfix branches: short branches from the release line for urgent production fixes
sh
git switch -c release/2.4 main
git tag -a v2.4.0 -m 'Release 2.4.0'
git push origin release/2.4 v2.4.0
Long-lived branches create merge debt. If a branch lives for weeks, the integration cost grows and the review becomes a batch risk rather than a small change.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1When would GitFlow be justified?
  2. 2How do you handle a hotfix while main has moved ahead?
  3. 3What makes a release branch different from a feature branch?
  4. 4How do you keep a long-lived release branch healthy?

Say it in the interview

I choose a branching model based on how often we release and whether we must support multiple versions. For frequent delivery I prefer short-lived branches into main, with feature flags for incomplete work. If we must maintain older versions, I cut release branches and cherry-pick fixes deliberately. I avoid long-lived develop branches because they hide integration risk until the end.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

MediumWhat is trunk-based development and how does it work in practice?MediumHow do feature flags change the deployment model?EasyWhat are the typical stages of a CI/CD pipeline?

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live CI/CD mock interview and get scored feedback on depth, clarity and confidence.

Start a free CI/CD interviewBrowse all questions