Q: When should you use `git rebase` instead of `git merge`, and what is the one rule you must never break?

Both integrate changes from one branch into another, but they produce very different histories.

• Merge preserves the actual branching history (creates a merge commit). Good for main/release branches where the history of *when things converged* matters.
• Rebase replays your commits on top of the target branch, producing a linear history with no merge commits. Good for cleaning up your local feature branch *before* opening a PR — it makes review easier and git log readable.

The one rule: never rebase commits that have been pushed and that other people are working on. Rebase rewrites commit hashes. If a teammate has pulled the old commits and you force-push rewritten ones, their next pull is a mess and they may re-introduce the old commits. Rebase your private branch all you want; never rebase shared branches like main or develop. Common workflow: rebase your feature branch onto latest main (git pull --rebase origin main), squash interactively (git rebase -i), force-push to your *own* feature branch, then merge the PR. --- ## 🔵 Undo, Recovery & History Rewriting