To understand whether this is safe, we first need to understand exactly why it’s necessary in the first place.

The Simple Explanation

A rebase takes a set of commits and replays them, one by one, onto a new starting point — effectively recreating each commit fresh, even if its actual code changes are identical to before. Every recreated commit gets a brand-new, unique identity, completely distinct from the original commit it was based on. This means that after a rebase, your local branch’s history is technically a different sequence of commits than what’s currently sitting on the remote, even though the two might look almost identical at a glance.

Why a Normal Push Gets Rejected

Git’s default push behavior includes a safety check specifically designed to prevent a branch’s history from being silently overwritten — it only allows a push that simply extends the remote’s existing history in a straight line. Since a rebase fundamentally replaces the old commits with new ones rather than extending them, a normal push is rejected, because Git correctly recognizes that your local and remote histories have diverged in a way it can’t automatically, safely reconcile.

Let’s be precise about exactly what happens on the remote when a force-push succeeds.

graph LR
    subgraph "Before Force-Push"
    R1[Remote branch points to old commits]
    end
    subgraph "After Force-Push"
    R2[Remote branch now points to your rebased commits]
    O[Old commits still exist temporarily, but nothing points to them]
    end
        

This single question is really the deciding factor for whether a force-push after a rebase is genuinely safe.

If a branch exists purely in your own, personal workspace — nobody else has ever pulled it, based their own work on it, or is currently reviewing it — then force-pushing after a rebase carries essentially no risk to anyone but yourself. But the moment someone else has a copy of that branch’s previous state, force-pushing creates a real, practical problem for them: their local history no longer matches the remote’s, and reconciling the two requires deliberate, manual effort on their part.

Let’s walk through exactly what a teammate experiences if they had already pulled a branch before it was rebased and force-pushed.

Let’s be concrete about the situations where force-pushing after a rebase carries essentially no real risk.

Git offers a meaningfully safer variant of force-pushing, worth understanding as a genuine best practice.

An ordinary force-push simply overwrites whatever is currently on the remote, no matter what that happens to be. A safer alternative first checks whether the remote branch has changed since you last looked at it, and refuses to proceed if it has — protecting against the specific, dangerous scenario where someone else has pushed new work to that branch in between your last fetch and your force-push, which an ordinary force-push would otherwise silently destroy.

graph TD
    A[You last checked the remote branch] --> B{Has anyone else pushed to it since?}
    B -- No --> C[Force-push-with-lease proceeds safely]
    B -- Yes --> D[Force-push-with-lease refuses, protecting the new work]
        

GitHub offers a repository-level safeguard specifically designed to prevent this entire category of risk on the branches that matter most.

Repository administrators can configure branch protection rules that explicitly block force-pushes to specific branches or patterns, most commonly applied to a project’s main branch and other long-lived, widely relied-upon branches. This removes the question of “is it safe?” entirely for those branches, by simply making a force-push impossible there in the first place, regardless of anyone’s individual judgment in the moment.

Force-pushing after a rebase is a genuinely useful capability, but it’s worth weighing its real benefits against its real risks honestly.

Teams that use rebasing regularly have converged on some clear, effective patterns, alongside recognizable mistakes to avoid.

A practical checklist for rebasing and force-pushing responsibly.

This exact question comes up constantly across teams of every size, and clear conventions have emerged around it.

Not immediately — the old commits typically remain in the repository’s underlying storage for a period of time, though nothing on the branch points to them anymore, and they’re eventually cleaned up over time.

Generally no, as long as nobody else has pulled a copy of it — the risk of force-pushing comes specifically from disrupting other people’s existing local copies, not from the operation itself.

Force-with-lease first checks whether the remote branch has changed since you last looked at it, refusing to proceed if someone else has pushed new work in the meantime — a normal force-push has no such check.

Yes — repository administrators can configure branch protection to block force-pushes on specific branches or patterns, commonly applied to main and other critical, shared branches.

They should discard their old local copy of that branch and fetch the newly rewritten version fresh from the remote, rather than attempting an ordinary pull, which can otherwise create a confusing, unnecessary merge.

It can be, but only with clear, deliberate communication beforehand, giving everyone a chance to save any in-progress work and prepare to refresh their local copy afterward.

A rebase always requires a force-push because it replaces a branch’s commits with brand-new ones rather than simply extending its history, and a normal push’s safety check correctly rejects that kind of divergence. Whether force-pushing afterward is genuinely safe comes down almost entirely to one question: does anyone else have an existing copy of that branch’s history? On a purely personal, unshared branch, the risk is essentially nonexistent. On a shared or widely relied-upon branch, it can genuinely disrupt collaborators, which is exactly why the safer force-with-lease variant, clear communication, and branch protection rules on critical branches all exist as sensible, complementary safeguards.