Choosing Per Situation: A Tester's Decision Table

Learning Objectives

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

• Choose merge or rebase for the situations a QA engineer actually meets
• Explain the "rebase locally, merge publicly" convention and why teams adopt it
• Identify which choice your repository's own history already implies
• Recognise git pull --rebase and know when it is the right default

Two Questions, In Order

Everything in this module reduces to a short decision path:

1. Do the commits exist outside my machine? If yes → merge. Stop here. This is the Golden Rule and it is not negotiable.

2. Is a clean, linear history worth anything here? If yes → rebase. If the branch is about to be squashed anyway, or the fork genuinely records something worth keeping, merge.

That is the whole decision. Everything below is that path applied to concrete cases.

The Table

"Rebase Locally, Merge Publicly"

Most teams that have thought about this land on one convention, and it is worth recognising by name:

• While a branch is yours, rebase it onto main as often as you like. Keep it current, keep it linear, clean it up before review.
• When the branch is done, merge it into main. That merge commit is the moment the work entered the product, and it is the thing you want to be able to find in six months.

It gets both benefits and pays for neither. Individual branches stay readable, and main keeps an honest record of what was integrated and when. The Golden Rule is never broken, because the rebasing all happens before anyone else is involved.

git pull --rebase

There is one more place the choice appears, and it catches people out.

A plain git pull on a branch where you have local commits and the remote has moved creates a merge commit — a tiny, meaningless one, saying nothing except "I pulled". A repository full of "Merge branch 'main' of github.com:..." commits is a repository where nobody configured this.

git pull --rebase

This fetches, then replays your local commits on top of the remote's, producing no merge commit. Since your local commits are, by definition, ones you have not pushed, the Golden Rule is safe.

Make it the default and stop thinking about it:

git config --global pull.rebase true

Pro Tip: This one setting removes more accidental merge commits from a team's history than any amount of discussion. It is also completely reversible, and it never touches anything you have already pushed.

Reading What Your Repository Already Decided

Before you introduce a convention, find out whether one exists:

git log --oneline --graph --all -30

A straight column means the team rebases and squashes. A wide braid of parallel lines means it merges. A straight line with occasional two-parent joins at main means "rebase locally, merge publicly" — the pattern above.

Matching the existing shape matters more than picking the theoretically better option. A history that is consistent can be read; a history where half the branches were rebased and half were merged cannot.

For the Tester Specifically

Your merge-or-rebase decisions mostly concern test-automation branches, and there the calculus is simple: those branches are usually short, usually yours alone, and usually reviewed. Rebase serves all three.

The one place to be careful is a long-running test branch that a second QA has also checked out — a shared regression suite update, say. The moment two people are on it, it is public, and the Golden Rule applies with no exception.

Key Takeaways

• Two questions decide it: is the history shared, and is linearity worth anything here
• Shared history is always merged, never rebased
• "Rebase locally, merge publicly" is the convention most teams converge on
• Interactive rebase before review is the highest-value use of rebase in the whole workflow
• git pull --rebase (or pull.rebase true) removes pointless merge commits from daily work
• Read git log --graph --all to see which convention a repository already follows, and match it