Short-lived feature branches — small commits, frequent merges, and the rebase trade-off

A short-lived feature branch is the unit of work that trunk-based uses to keep the trunk deployable while preserving review isolation. The branch is created from the trunk, carries one change-set through one pull request, and is merged back within hours — ideally the same working day. The branch is not a long-lived fork; it is a temporary scaffold for one commit’s worth of review.

The discipline that makes short-lived branches safe is keeping them current with the trunk. A branch created Monday and merged Friday has four days of divergence; a branch created Monday morning and merged Monday afternoon has hours.

The shape of a short-lived branch

Three properties define the shape: (1) one change-set (one logical change — a new Terraform resource, not a refactor plus a feature plus a fix); (2) one pull request (one description, one set of reviewers, one merge); (3) hours, not days.

BRANCH="feature/$(whoami)-example"

git switch main
git pull --rebase
git switch -c "$BRANCH"

# ... work, commit, push ...

git fetch origin
git pull --rebase

git switch main
git pull --rebase
git merge --no-ff "$BRANCH"

git branch -d "$BRANCH"

The sequence shows the trunk-based cycle: create from main, work in small commits, pull the trunk with --rebase to stay current, merge back with --no-ff to record the integration event, delete the branch.

The rebase-versus-merge trade-off

When a feature branch needs to incorporate new trunk commits, the engineer has two verbs. Rebase rewrites the feature branch’s commits on top of the trunk tip (linear graph, fast-forward or --no-ff merge back). Merge creates a merge commit on the branch that joins the trunk tip (forked graph, merge commit visible).

flowchart LR
    A["main: a-b-c"] --> R1["feature: a-b-c-d-e-f"]
    R1 -->|"rebase"| R2["feature: linear"]
    M["main: a-b-c"] --> G1["feature: a-b-c-d-e"]
    G1 -->|"merge"| G2["feature: forked"]

The rebase path produces a linear feature branch; the merge path produces a forked one. Both produce a working branch; they differ in graph readability and audit ease.

Why short-lived beats long-lived

Three costs accumulate when a branch lives too long. Conflict accumulation: a four-day divergence produces conflicts that are often semantic (the trunk renamed a resource, the branch references the old name) and cannot be resolved mechanically. CI cache invalidation: each push after a rebase invalidates commit-derived cache keys, costing repeated cold runs. Review staleness: a reviewer who re-reads on Friday has lost Monday’s context, turning the review into a tax on attention.

The relevant configuration:

git config --global pull.rebase true
git config --global branch.autosetuprebase local
git config branch.feature.rebase true
git config branch.main.rebase false

With pull.rebase = true and branch.autosetuprebase = local, every git pull on a feature branch becomes git pull --rebase. Engineers who want to merge instead must opt in with git pull --no-rebase, surfacing the choice as a deliberate act.

Production discipline

1. One change-set, one PR, one merge. Splitting a branch into multiple PRs is a sign that the branch carries too much.
2. Rebase before review; never rebase during review. Rebasing rewrites shared history; the rule is to rebase freely before review, never during.
3. Pull with rebase by default. pull.rebase = true and branch.autosetuprebase = local enforce the default verb at the configuration level.
4. Trunk-aware rebase cadence for long-lived branches. If a branch must live for more than a day, rebase onto the trunk tip every morning. Divergence never exceeds one working day.
5. Delete the branch after merge. git branch -d removes the ref but keeps commits reachable through the merge.

Cross-course references

• CI/CD Pipeline Patterns - Part IV (BranchProtection) covers server-side protection that prevents force-pushes to protected branches.
• GitOps with Argo CD - Part V (PRWorkflows) covers the PR workflow that corresponds to short-lived branches.
• Terraform for Production Sysadmins - Part XI (PRWorkflows) covers the Terraform analogue: each PR is one plan.

Quiz