Never Rebase Shared History

The Golden Rule: Never Rebase Shared History

Rebase only commits that exist nowhere but in your repository. Once others have fetched a branch, rebasing it replaces commits they build on with copies; when they pull, the old commits come back through a merge, duplicated, or their work conflicts with your rewrite. The force-push that publishes a rewrite (--force-with-lease) is the moment to stop and check. Rebase your own branch freely before pushing it, and afterward only if nobody else uses it; never rebase main. The pagination branch was private, so it joins main as a fast-forward:

Fast-forwarding main to the rebased branchShell
git switch -q main
git merge -q --ff-only paginate-api
git branch -d paginate-api
git log --oneline -5
Output
Deleted branch paginate-api (was dfab226).
dfab226 Document ?limit= and ?offset= in the README
10465b8 Add ?offset= to /api/books
f4655d6 Add ?limit= to /api/books
1821d5c Break sort ties by id so pages are stable
e78d7c2 Pin Node.js 24 with .nvmrc

Compare this straight line with the merge graph of Feature Branches; Linear History shows how teams choose.