Rebase vs merge
Join histories with a merge commit. Preserves what actually happened, never rewrites commits, safe on shared branches. Cost: a history graph full of merge bubbles that makes git log --graph noisy.
Replay your commits onto the new base, producing a straight line. Clean linear history, easy bisecting. Cost: rewrites commit hashes - anyone who pulled your old commits now has divergent history.
Collapse the whole branch into one commit on main. Tidy main, easy reverts of whole features; loses the individual-commit narrative.
The golden rule decides most of it: never rebase commits that others may have pulled. Standard workflow: rebase your private feature branch onto main to stay current (git pull --rebase), then merge or squash-merge into main. Pick squash when the team treats PRs as the atomic unit; pick true merge when individual commits in a feature matter (e.g. separated refactor + behavior change). In the interview, naming the golden rule is the pass/fail line.