When should I use force push?

Use force push only on branches where you intentionally rewrote commit history, such as interactive rebase or commit squash. Prefer force-with-lease over force.

Why is --force-with-lease safer than --force?

--force-with-lease aborts if the remote branch changed unexpectedly, so you do not overwrite teammates' newer commits by accident.

How do I recover after a bad force push?

Use git reflog to find the previous branch tip, create a recovery branch, and push the corrected history after team confirmation.

Git Force Push Safety Checklist: Diff, Lease, and Recovery Commands (2026)

Published February 25, 2026 · 8 min read

Force push is not inherently bad. It is a precision tool for branches where you intentionally rewrote history, usually after interactive rebase or squash. The risk comes from skipping verification steps.

⚙ Run these tools before force push: Validate changed hunks in Git Diff Viewer, compare before/after text in Text Compare, and finalize one clear message with Git Commit Message Generator.

This checklist gives a repeatable workflow you can run in under five minutes to avoid accidental branch overwrite and message drift.

When force push is appropriate
Pre-push safety checklist
Safe force-push command pattern
Recovery flow if something breaks
FAQ

1. When force push is appropriate

Use force push when branch history changed on purpose:

You squashed WIP commits into one logical commit.
You rebased onto updated main and commit hashes changed.
You removed accidental secrets from a personal branch commit history.

Avoid force push on shared integration branches. If multiple people already pulled the branch, coordinate first or prefer additive commits.

2. Pre-push safety checklist

Check	Command	Outcome
Fetch latest remote state	`git fetch origin`	Lease check is based on fresh refs
Verify branch head	`git status -sb`	Confirms target branch and clean working tree
Inspect rewritten diff	`git diff origin/feature/my-branch...HEAD`	Ensures no expected hunk disappeared
Check commit message quality	`git log --oneline -n 5`	Confirms final commit text is reviewer-friendly

If your CLI diff is noisy, review a cleaner side-by-side in Git Diff Viewer before pushing rewritten history.

3. Safe force-push command pattern

# Always prefer lease-based overwrite
git push --force-with-lease origin feature/my-branch

# Optional explicit lease pin
git push --force-with-lease=refs/heads/feature/my-branch origin feature/my-branch

Team-safe default: If --force-with-lease fails, stop and inspect remote updates instead of retrying with --force.

4. Recovery flow if something breaks

# 1) Find previous branch tip
git reflog

# 2) Create a recovery branch
git checkout -b recovery/force-push-rollback <good-hash>

# 3) Push recovery branch for review
git push origin recovery/force-push-rollback

For full command context, keep Git Reflog Recovery Guide and Git Undo Last Commit Guide in your incident notes.

5. FAQ

Is force push always dangerous?

No. It is safe on personal branches when you verify diff integrity and use --force-with-lease.

Should I force push after every interactive rebase?

If the branch was already pushed, yes, because commit hashes changed. Use lease mode and communicate in the PR thread.

How do I make squashed commit messages clearer?

Use one intent-first subject line and concrete body bullets. Draft quickly with Git Commit Message Generator.