🌿Developer

Git Workflow That Actually Works for Small Teams

Git Flow is too complex for most projects. Trunk-based development confuses people. Here's a simple, practical Git workflow for teams of 2–10.

6 min readJanuary 28, 2026By FreeToolKit TeamFree to read

Most Git workflow advice was written for teams of 50+ or for open-source projects with external contributors. Small product teams have different constraints. Here's a workflow that's served teams of 2–10 well without the overhead of Git Flow and without the deployment confidence required for full trunk-based development.

The Simple Version

Main branch = production. Feature branches = your work. Short-lived (under a week). PR + review before merge. Delete branches after merge. That's 90% of the workflow. Everything else is refinement.

Commit Message Conventions

Conventional Commits (fix: title, feat: title, chore: title) are worth adopting even for small teams. They enable automatic changelog generation and make git log readable. The investment is one learning session and you get years of readable history. More importantly, 'fix: resolve null pointer in user auth' tells you more than 'fixed stuff' when you're debugging 6 months later.

Branch Naming

Simple naming reduces confusion: feat/short-description, fix/bug-description, chore/task-description. Some teams add ticket numbers (feat/FTK-123-user-auth). Whatever format you choose, apply it consistently. Random branch names ('johns-branch', 'test2', 'final-final') make cleanup and reference miserable.

The Squash Merge Debate

Squash merging combines all commits in a PR into one before merging. Pros: clean main branch history with one commit per feature. Cons: you lose the individual commit context from development. For small features, squash is fine. For large features where the commit history documents important decisions, regular merge preserves more information. Many teams default to squash for everything and accept the trade-off.

Protecting Main

Enable branch protection on main: require PR reviews, require status checks (CI passing), and prohibit force pushing. These three rules prevent the most common accidents: pushing directly to main, merging failing code, and rewriting shared history. Set these up on day one of a new project — it's harder to add them after bad habits form.

Git aliases worth setting

'git lg' showing a compact, colored log graph is genuinely useful. Add to your .gitconfig: [alias] lg = log --oneline --graph --decorate --all. Run 'git lg' and you get a visual representation of your branch structure in 15 lines or less.

Frequently Asked Questions

What is trunk-based development?+

Trunk-based development means everyone commits to a single main branch (the 'trunk') rather than maintaining long-lived feature branches. Feature flags hide incomplete work in production. It's the workflow used by Google and other large tech companies and is strongly associated with continuous integration and delivery. The advantage: no merge hell. The challenge: requires feature flags and confident deployment practices that smaller teams often lack.

What's wrong with Git Flow?+

Git Flow (main, develop, feature, release, hotfix branches) was designed for software with scheduled releases and was influential when it appeared in 2010. It's significant overhead for most modern web projects that deploy continuously. Maintaining develop and release branches separately from main creates confusion about which is the 'truth.' Many teams adopt Git Flow and abandon parts of it as they discover which branches they actually use.

How long should a feature branch live?+

As short as possible — ideally under a week. Long-lived branches diverge from main and create large merges. Large merges create conflicts. Conflicts create pain. The discipline of breaking work into small, mergeable increments is harder to learn than the mechanics of rebasing, but it has more impact on team velocity than any tooling choice.

Should I rebase or merge?+

Prefer rebase for keeping feature branches current with main (rebase your branch on main rather than merging main into your branch — cleaner history). Use merge for incorporating feature branches into main on GitHub/GitLab via pull requests — this preserves the PR context in history. This hybrid ('rebase and merge') is the default on many platforms and produces readable git log output without excessive merge commits.

🔧 Free Tools Used in This Guide

Json Formatter

FreeToolKit Team

We build free browser-based tools and write practical guides that skip the fluff.

Tags:

gitdeveloperworkflowversion control

Continue Reading

💻

VS Code Extensions That Actually Save Time (2026 Edition)

6 min read