Q2 of 40 · Git

When is force-push safe and when is it dangerous?

GitMidgitforce-pushforce-with-leasegit-safetyteam-workflow

Short answer

Short answer: Force-push is safe on a private branch only you have checked out, after a local rebase or reword. It's dangerous on any shared branch — it rewrites remote history and orphans everyone else's local commits. Use --force-with-lease instead of --force: it only pushes if the remote hasn't moved since your last fetch.

Detail

git push --force replaces the remote branch's history with your local history, regardless of what's there. If anyone else has based commits on the old history, their local branch now diverges from remote in a confusing way that's hard to recover from.

When force-push is safe:

  • Your own feature branch, after an interactive rebase to clean up commits before opening a PR, when nobody else has fetched your branch.
  • Correcting a mistaken commit (wrong author email, accidentally committed a secret) on a branch that hasn't been shared.

When it's dangerous:

  • main or develop — almost never acceptable. Most repo hosts protect these branches from force-push by default.
  • Any branch other people are actively working from or that CI has used as a base.
  • After a PR review has started — reviewers' local checkouts now diverge from remote.

--force-with-lease: a safer alternative. Git checks that the remote ref matches what your local fetch cache recorded. If someone else has pushed since you last fetched, the push fails with a clear error instead of silently overwriting their work. Always prefer --force-with-lease over --force.

Recovery: if you accidentally force-pushed over commits, git reflog on your local clone can recover lost commits. On GitHub, commits aren't immediately garbage-collected — a repo admin can sometimes recover them within the GC window via the web API or GitHub support.

// EXAMPLE

# Safe: clean up a PR branch before review opens
git checkout feature/user-auth
git rebase -i HEAD~3        # squash and reword last 3 commits
# Local history now diverges from remote (new hashes after rewrite)

# Safer force: fails if remote moved since your last fetch
git push --force-with-lease

# Dangerous — overwrites regardless of remote state
# git push --force  ← avoid

# Set up a git alias for convenience
# ~/.gitconfig:
# [alias]
#   pushf = push --force-with-lease

# Recovering lost commits after an accidental force-push
git reflog                  # shows every place HEAD has pointed
git checkout <lost-sha>     # check out the lost commit
git branch recovery/rescue  # save it to a new branch

// WHAT INTERVIEWERS LOOK FOR

Clear distinction between private and shared branches, the --force-with-lease recommendation as a safer alternative, and awareness of branch protection rules. A good senior answer mentions accidental force-push recovery via reflog.

// COMMON PITFALL

Thinking --force-with-lease is fully safe. It's safer than --force, but it doesn't protect against cases where you're force-pushing a branch that someone else also has locally and has made changes on. Clear team communication is still required.

// Related questions

How does `--force-with-lease` protect against overwriting a colleague's work, and when can it still fail?

Git

A teammate accidentally force-pushed to `main` and lost 3 commits that were never backed up. How do you recover them?

Git

Describe a time you made a mistake at work. How did you handle it?

Behavioural