Rewriting history with git rebase feels powerful. It gives you cleaner commits, a tighter narrative, and the satisfaction of mastered order. But under the surface, it changes the very DNA of your repository. Understanding the immutability—and the illusion of it—is essential if you want control instead of chaos.
Git isn’t a database that guarantees perfect permanence. Its immutability feels absolute because commits are identified by cryptographic hashes. But a rebase creates entirely new commits, even if the content seems identical. Those new commits point to new histories. The original commits are abandoned, replaced in the reference path. Every coworker with those old commits now lives in a parallel timeline until they reconcile with yours.
This is why git rebase on public branches can be dangerous. You’re not “moving commits.” You’re creating new ones and discarding the old pointers. Colleagues pulling your rebased branch get merge conflicts they never caused. When misunderstood, a rebase turns even the cleanest project into a puzzle of diverging histories.