Mastering Git Branching Models for a Smooth Development Workflow

A branching model is a set of conventions for how branches get created, named, used, and deleted in a repository. The right model keeps development organized without getting in the way. The wrong one creates merge hell.

Git branching strategies

The most referenced model is Git Flow, with five branch types: master, develop, feature, release, and hotfix. For most teams that’s more ceremony than needed. A simpler three-branch setup works well:

• Development — where features are built. Each feature gets its own branch off development, merged back when done and tested locally.
• Staging — integration and QA. When a batch of features is ready for more rigorous testing, development merges into staging, which mirrors production.
• Master — production. Only code that’s passed staging testing gets here.

Branch protections

To keep the mainline branches clean, set up branch protection rules on staging and master:

• Require pull request reviews before merging
• Require status checks to pass (tests, linting)
• Prevent force pushes

This ensures nothing goes to production without review and green CI. It also creates a useful paper trail — every change to master has an associated PR with context on why it was made.

Tags and releases

Git tags mark specific commits as meaningful — typically version releases. When code is ready for production (merged into master), create a tag:

git tag -a v1.2.0 -m "Add user authentication"
git push origin v1.2.0

Tags make rollbacks straightforward. If something breaks in production, you can identify exactly which commit introduced it and revert to the previous tag.

A typical feature flow

1. Create feature/user-auth off development
2. Build, test locally, push
3. Open PR → development, get review, merge
4. When enough features are ready, merge development → staging
5. Deploy staging, run QA
6. Merge staging → master, tag the release
7. For hotfixes: branch directly off master, fix, merge back to both master and development

The exact workflow varies by team size and release cadence, but the principle is consistent: isolate development work, protect the branches that matter, and tag what ships.