Rebase Best Practices and Safety

What

Because git rebase works by rewriting history (generating new commit hashes for existing changes), it is a powerful tool that comes with one critical security constraint: The Golden Rule of Rebase.

How

To avoid breaking collaborative workflows, adhere strictly to these rules:

Never rebase public branches: Do not rebase branches that have already been pushed to a remote server and are being shared or checked out by other developers (such as the default main branch).
Only rebase private branches: It is perfectly safe to rebase your own local, private feature branches onto a shared base branch before submitting them for code review:

# SAFE: Rebasing your private local feature onto public main
git switch my_private_feature
git rebase main

# DANGEROUS: Rebasing public main onto your private feature (Do NOT do this!)
git switch main
git rebase my_private_feature

Why

Rebasing a public branch changes the commit hashes of history that other team members have already built their own work on. If you rewrite those hashes and force-push them to the remote server, Git will treat the history as completely broken and out of sync for everyone else, leading to severe merge issues, duplicate commits, and developer headache.

Choosing between rebase and merge is about balancing priorities:

git merge: Safely preserves the raw, actual historical timeline and shows exactly when branches integrated, but can clutter history with automatic merge commits.
git rebase: Keeps the history extremely clean, linear, and easy to read, but changes the commit signatures.

Summary

The Golden Rule of Rebase states you must never rebase public or shared branches, though it is safe and encouraged to rebase your private, local feature branches onto public baselines.