The Golden Rule of Git Rebase

The practical rule is not to rewrite commits that collaborators depend on without coordinating with them. The reason is how rebase works under the hood. When you rebase, Git replays each commit with a new parent, and because a commit's hash is calculated from its content plus its parent, every replayed commit gets a brand-new SHA. The code is identical, but Git treats it as a different commit. Now picture the team impact. I push my feature branch, and a teammate pulls it to collaborate, so they have commits with specific hashes locally. If I then rebase and force-push, the remote has new hashes for what looks like the same work. When my teammate pulls, Git sees their old hashes and the new remote hashes as two divergent histories it can't reconcile, so they get errors and often have to reset their branch, which can lose any work they built on the old commits. It's even worse on a branch like main or develop, because then everyone's clone diverges at once and nobody can cleanly push or pull. So the practical takeaway is that once commits are shared, they're effectively immutable — if I need to bring in new changes after pushing, I use merge instead of rebase. I can rebase all I want on a private branch before pushing. And if I ever truly have to force-push my own private branch, I'd use force-with-lease rather than a plain force, because force-with-lease refuses to overwrite remote commits I haven't actually seen yet.