Git Workflows That Actually Work for Small Teams

I have been on teams with wildly different Git workflows. Long-lived feature branches, strict Gitflow, trunk-based development, no rules at all. Here is what I think actually matters.

Branch Lifetime

The single thing that causes the most Git pain is long-lived branches. The longer a branch lives, the more it diverges from main, the more painful the merge. I have spent full days resolving merge conflicts on branches that were open for three weeks.

My preference now: branches should live for at most a few days. If a feature takes longer than that, break it into smaller pieces that can each merge independently. Feature flags let you merge code that is not yet user-visible.

PR Size

Small PRs get reviewed faster and more thoroughly. A 50-line PR with a clear description will get reviewed in 20 minutes. A 500-line PR might sit for two days and get rubber-stamped because nobody wants to dig through it.

I try to keep PRs under 200 lines of meaningful change (not counting generated files, lockfiles, etc.). If a PR is getting large, it is usually a sign that I combined two things that could have been separate.

Commit Messages

I follow the conventional commits format: type(scope): description. For example: fix(auth): handle expired tokens on session refresh.

This is not because it looks nice. It is because tools can parse it. Automated changelogs, version bumping scripts, and release notes all become easier when your commits are structured.

The body of the commit message is where I explain why, not what. The diff shows what changed. The message should explain the reasoning, especially for non-obvious decisions.

Rebase vs Merge

I rebase feature branches on main before merging, so the history stays linear and readable. Merge commits that say "Merge branch feature/add-login into main" do not add information.

For long-lived branches where multiple people are collaborating, merging makes more sense because rebase rewrites history and causes problems for other contributors.

What I Stopped Caring About

Perfect commit history on a feature branch. While I am working, I commit often with rough messages. Before the PR is ready, I clean up with interactive rebase. But I do not stress about this process. The goal is a clean history on main, not a journal of every step I took while working.

The things that matter: small PRs, short branch lifetimes, clear commit messages on merge. Everything else is secondary.