Most small teams do not need an elaborate branching model with release, hotfix and develop branches all running in parallel. What they need is a workflow that is easy to remember, keeps the main branch deployable and makes code review quick. This guide describes a trunk-friendly approach that works well for teams of two to ten developers.
Keep main always deployable
The single most useful rule is that main should always be in a state you could ship. Nobody pushes directly to it. Every change arrives through a pull request that has passed automated tests and at least one review. When something breaks, you know the problem came from the most recent merge, which makes debugging far simpler.
Protect the branch in your Git host settings: require status checks to pass, require a review, and block force pushes. These guard rails cost nothing and prevent the most painful accidents.
Use short-lived feature branches
Create a branch for each piece of work and aim to merge it within a day or two. Long-lived branches drift away from main, collect conflicts and produce enormous pull requests that nobody wants to review properly.
- Name branches by intent. Prefixes such as feat/, fix/ and chore/ followed by a short description or ticket number make the branch list readable.
- Split big features. Ship the database migration first, then the backend logic, then the UI, each behind a feature flag if needed.
- Rebase or merge main often. Pull in the latest changes daily so conflicts stay small.
git switch -c feat/invoice-pdf-export
# work, commit in small steps
git fetch origin
git rebase origin/main
git push -u origin feat/invoice-pdf-exportWrite commits and pull requests for reviewers
A reviewer should understand what changed and why without opening a chat window. Keep commits focused, write messages in the imperative mood ("Add PDF export for invoices") and use the pull request description to explain context, trade-offs and how to test.
A good rule of thumb is that a pull request should be reviewable in about fifteen minutes. If it is larger, ask whether it can be split. Smaller pull requests get faster, more thorough reviews and are easier to revert.
Decide on a merge strategy and stick to it
Teams argue endlessly about squash merges versus merge commits. Both work; inconsistency is the real problem. Many small teams prefer squash and merge, because each pull request becomes one tidy commit on main that is easy to revert. If you value detailed history, use rebase and merge with clean commits. Pick one and configure the repository to allow only that option.
Tag releases instead of maintaining release branches
For web applications that deploy continuously, a separate release branch is usually unnecessary. Instead, tag the commit you deploy using semantic versioning or a date-based scheme. If you need to patch production urgently, branch from the tag, fix, tag again and merge the fix back into main.
git tag -a v1.8.0 -m "Release 1.8.0"
git push origin v1.8.0Automate the boring checks
Let continuous integration run linters, formatters, static analysis and tests on every pull request. When formatting is automatic, reviews can focus on logic and design instead of spacing and semicolons. A pre-commit hook that runs the formatter locally saves another round trip.
Handle mistakes calmly
Everyone eventually commits to the wrong branch or pushes something half-finished. Learn a few recovery commands: git reflog to find lost commits, git revert to undo a merged change safely on a shared branch, and git restore to discard local edits. Avoid rewriting history on any branch other people have pulled.
Wrapping up
A good Git workflow fades into the background. Protect main, keep branches short, make pull requests small and readable, automate checks and tag what you ship. Write the rules down in a short CONTRIBUTING file so new teammates can follow them from day one, and revisit them every few months as the team grows.
