Rebase vs Merge

Rebase Versus Merge: Rewriting History on Purpose

git rebase main sets aside your branch's commits that main lacks, moves the branch to main's tip, and replays each as a new commit with a new parent and hash, as if the work had started today (8).

Merging keeps the fork; rebasing replays the branch's commits on the new tip
Merging keeps the fork; rebasing replays the branch's commits on the new tip

Rebase trades truth for readability. git log and git bisect (git bisect) work best on a straight line of commits that each pass the tests, and reviewers prefer clean steps to a trail of "wip" and "fix typo". The price: rebased commits are new objects, so anyone holding the old ones now has a diverged copy (Never Rebase Shared History).