Most teams don't need Git Flow's five branch types and release branches — they need one rule, consistently followed: main is always deployable. Everything else follows from that.
Step 1: branch per feature
git checkout main
git pull
git checkout -b feature/add-searchEvery unit of work — a feature, a fix, a refactor — gets its own short-lived branch off the latest main. Naming it by intent (feature/, fix/) makes the branch list self-documenting.
Step 2: commit in small, honest steps
git add src/search.js
git commit -m "Add debounced search input"Small commits with clear messages are what make git log and git blame actually useful later. Squashing a messy branch into one clean commit at merge time is fine — the point is the history main ends up with, not every intermediate commit.
Step 3: open a pull request early
Push the branch and open a PR even before the work is finished — draft PRs give reviewers visibility and let CI run continuously, catching problems before they compound.
git push -u origin feature/add-searchStep 4: rebase to stay current
git checkout feature/add-search
git fetch origin
git rebase origin/mainRebasing replays your commits on top of the latest main, avoiding a tangle of merge commits and keeping the eventual merge simple. Never rebase a branch other people are also committing to — it rewrites history and breaks their clones.
Protect main. Require passing CI and at least one review before a PR can merge. This single setting is what actually enforces "always deployable" — without it, the rule is just a suggestion.
Step 5: merge and delete
Once approved and green, merge (squash or regular, per your team's preference) and delete the feature branch immediately. A repository with dozens of stale merged branches makes it hard to tell what's actually in progress.
Why this scales
This workflow doesn't change shape whether you're a team of two or two hundred — more people just means more branches in flight at once, not a different process. That's the whole point of keeping it simple.
Comments