DEV Community

Idev.d
Idev.d

Posted on Originally published at idev.my

Git Branch Strategy for Small Teams: What Actually Works

In our early days at iDev, we made every Git mistake in the book: constant merge conflicts, chaotic releases, nobody knew which branch to hotfix from.

After trying Git Flow, GitHub Flow, and Trunk-Based Development, here is what actually works for a 5-10 person team.

The Problem with Git Flow

Git Flow (main, develop, feature, release, hotfix) is designed for large teams with scheduled releases. For a small team shipping continuously, it is overkill: too many long-lived branches, merge conflicts pile up, release branches add ceremony with no value.

What We Actually Use: Enhanced GitHub Flow

1. main is always deployable

Protected branch. Only merge via PR. If main is broken, everything stops until it is fixed.

2. Short-lived feature branches

Branch from main, PR back to main. Branch lifespan: ideally under 3 days.

3. PR rules

  • At least one review approval
  • CI must pass
  • Squash merge to keep main history clean

4. Daily habits

Start of day: sync with main via rebase. Stash unfinished work instead of committing half-done code. Clean up merged remote branches periodically.

5. The One Rule That Changed Everything

Rebase before opening a PR. Not merge, rebase. This keeps the PR diff clean (only your changes, no merge commits) and makes review dramatically easier.

Summary

For teams of 5-10: Enhanced GitHub Flow beats Git Flow and Trunk-Based. The strategy is not revolutionary. The discipline of following it consistently is what makes the difference.


Small team, big output. iDev builds web apps, AI solutions and custom systems with startup speed and enterprise quality. Based in Malaysia, serving Southeast Asia. Free consultation.

Top comments (0)