Keeping Your Test Branch Fresh from main

Learning Objectives

By the end of this lesson you will be able to:

Explain why a stale test branch produces misleading test results
Update your branch from main correctly and safely
Choose sensibly between merging main in and rebasing onto it
Decide how often to refresh, based on how fast your main moves

The Problem With Standing Still

You branched off main on Monday morning. It is now Thursday. In between, eleven commits landed on main, including a fix to the session-handling code your tests exercise on every single run.

Your branch does not have any of them. Which means:

Failures you report may already be fixed. You file a bug, a developer looks, and it doesn't reproduce on current code. Everyone loses twenty minutes.
Passes you report may be meaningless. Your suite is green against Monday's code. Nobody ships Monday's code.
The eventual merge gets harder. Three days of divergence is three days of potential conflicts, arriving all at once at the least convenient moment.

The fix is not complicated. It is just a habit.

Refreshing by Merging

The safe, conventional approach — merge main into your branch. Note the direction: this is the opposite of releasing.

git switch main
git pull                             # get the latest main from the server
git switch test/PAY-4417-verify      # back to your branch
git merge main                       # bring main's work in

Your branch now contains everything from main plus your own work. main itself is untouched.

BEFORE                              AFTER

A───B───C───D      ← main           A───B───C───D      ← main
     \                                   \       \
      E───F  ← test/PAY-4417-verify       E───F───M    ← test/PAY-4417-verify

If main changed lines your branch also changed, you will get a conflict here — and that is the point. You resolve it now, on your own branch, at a moment you chose, rather than during a release.

The Shortcut

git switch test/PAY-4417-verify
git merge origin/main

This merges the server's main directly, without switching branches, and works after any git fetch. It is what most people end up using. Just remember that origin/main is only as current as your last fetch — run git fetch first.

Refreshing by Rebasing

The alternative:

git switch test/PAY-4417-verify
git rebase main

Rebase replays your commits on top of the current main, as if you had branched this morning instead of on Monday.

BEFORE                              AFTER

A───B───C───D      ← main           A───B───C───D            ← main
     \                                           \
      E───F  ← test/PAY-4417-verify               E'───F'    ← test/PAY-4417-verify

The history stays linear and there is no merge commit. It reads beautifully.

There is a cost, and it is important: E' and F' are new commits with new IDs. The originals are gone from the branch. That is fine for a branch only you have touched, and genuinely disruptive for a branch anyone else has pulled — their copy and yours now disagree about history, and fixing that is unpleasant.

The Rule

Never rebase a branch that other people have pulled.

For a personal test branch nobody else uses, rebase is safe and produces a cleaner history. For anything shared, merge. If you are unsure which category you're in, merge — the worst outcome is an extra commit in the log.

Many teams have a stated policy on this. Ask; don't guess.

How Often

Match your refresh rhythm to how fast main moves:

`main` moves	Refresh
Several times a day	Every morning
A few times a week	Before each test session
Rarely	Before starting, and before merging back

And unconditionally: refresh before you report a bug. Confirming the defect still exists on current code takes two minutes and saves a round trip through the whole team.

Pro Tip: After refreshing, re-run your suite before doing anything else. A test that broke because of main's changes and a test that broke because of the feature look identical in a report — but only if you didn't check.

Key Takeaways

A stale branch produces bug reports that don't reproduce and green runs that mean nothing
git merge main from your branch brings main's work in and leaves main alone
git merge origin/main does it without switching branches — fetch first
git rebase main replays your commits on top of main for a linear history, but rewrites their IDs
Never rebase a branch other people have pulled; when in doubt, merge
Refresh on a rhythm that matches main, and always before filing a bug