rebase vs merge, the short answer

Anyone new to git eventually asks which to use. The arguments online get theological fast, which is unhelpful. Here's how I actually decide.

the rule I use

Use rebase while your branch is local and unpublished. Use merge once others might be looking at it.

That's it. Both are valid operations. Mixing them is fine. The mistake is rewriting shared history, not choosing wrong up front.

why

Rebase makes the history read like a story: one thing happened, then the next, then the next. That's what I want when I open a PR six months later and try to understand why a commit exists.

But rebase changes commit hashes. If anyone else has pulled those commits, you've now orphaned their copy. So as long as nobody's pulled from you, rewrite freely. After that, merge.

the workflow I land on

git checkout -b feat/thing
# ... work, commit, work, commit
git fetch origin
git rebase -i origin/main     # clean up locally
git push origin feat/thing
# open PR, reviews come in
git commit -m "address review"
git push
# merge via GitHub squash or rebase-merge

I squash at the PR boundary because I care about the main branch reading clearly, not the branch being a record of my fumbling.

the one thing I don't do

I never git push --force to main. I will force-push to my own branch constantly. Different risk.