Introduction

A forced push to another branch in Git means sending your current local commit history to a remote branch name and overwriting that remote branch even if the histories do not fast-forward. The syntax is straightforward, but the risk is real because you can erase commits that exist only on the remote.

The safe way to think about this command is not “how do I force push” but “which local ref do I want to publish, which remote ref do I want to replace, and how do I protect myself from clobbering someone else’s work.”

The Basic Command

If you want to push your current HEAD to a different remote branch, the pattern is:

git push --force-with-lease origin HEAD:target-branch

This means:

• push the commit at local HEAD
• update origin/target-branch
• allow rewriting history if needed
• refuse the push if the remote branch changed unexpectedly since your last fetch

--force-with-lease is safer than plain --force because it adds a basic concurrency check.

Example Workflow

Suppose you are on a local branch named rewrite-docs, and you need to replace the remote branch staging-docs with that history.

1git fetch origin
2git status
3git log --oneline --decorate -n 5
4git push --force-with-lease origin rewrite-docs:staging-docs

You do not need to check out staging-docs locally to do this. Git can map one local ref to a different remote ref directly.

If you are already on the local branch you want to publish, HEAD:staging-docs is equivalent.

When Plain --force Is Used

Plain --force removes the protection that --force-with-lease provides:

git push --force origin HEAD:target-branch

This will overwrite the remote branch even if someone else pushed new commits after your last fetch. Use it only when you are certain you own the branch history and there is no collaboration risk.

For shared branches, --force-with-lease should be your default.

Verify the Refs Before You Push

Before rewriting a remote branch, inspect both sides. A short checklist helps avoid expensive mistakes:

1. fetch the remote
2. confirm your current branch and commit
3. inspect the remote branch tip
4. confirm that replacing the remote history is intentional

These commands are useful:

1git fetch origin
2git rev-parse --short HEAD
3git rev-parse --short origin/target-branch
4git log --oneline --left-right HEAD...origin/target-branch

That last comparison makes it much easier to see which commits exist only locally and only remotely.

Know How to Recover

If you make a mistake, recovery is often possible as long as someone still has the old commits in their local clone or reflog. That is another reason to coordinate before force-pushing a shared branch. A quick safety habit is to create a backup ref before rewriting:

git branch backup-before-force-push
git push origin backup-before-force-push

That extra branch gives you an easy rollback point if the remote branch was replaced with the wrong history.

Common Pitfalls

• Using --force when --force-with-lease would have provided a safer check.
• Forgetting the refspec direction and pushing the wrong branch to the wrong remote target.
• Force-pushing to a shared integration branch without coordinating with the team.
• Skipping git fetch and working from stale knowledge of the remote branch.
• Assuming you must check out the destination branch locally before pushing to it.

Summary

• To force-push your current work to another remote branch, use git push --force-with-lease origin HEAD:target-branch.
• The local:remote refspec lets you publish one local branch to a differently named remote branch.
• Prefer --force-with-lease over plain --force.
• Fetch and compare branch tips before rewriting remote history.
• Treat forced pushes as deliberate history replacement, not a routine save command.