Git rebase can rewrite commits into a sleek, linear history, but sometimes that rewrite is a liability. You can lose context. You can disrupt collaboration. You can break CI pipelines that depend on commit hashes. That’s why Git rebase opt-out mechanisms exist — to prevent rebase when it causes more harm than good.
An opt-out mechanism isn’t magic. It’s policy, tooling, and guardrails built into the workflow. The simplest is team agreement: don’t rebase on protected branches. Enforce it with branch protection rules in GitHub, GitLab, or Bitbucket. Configure settings to reject pushes with rewritten history.
Another layer is server-side Git hooks. A pre-receive hook can compare incoming commits with the branch tip, detect rewrites, and reject the push if a rebase was performed. These hooks live on the Git server and work no matter which client or IDE connects.
Local enforcement is possible too. Pre-push hooks can check for non-fast-forward updates before sending them. If a commit history rewrite is detected, the push fails instantly. This stops destructive rebases at the source.