Why You Should Avoid Blindly Using git push --force

Git push mistakes and the temptation to force‑push

After pushing a commit that contains test code, a wrong configuration, or an obvious bug, many developers instinctively run git reset --hard HEAD~1 followed by git push --force. Once a commit is pushed, other developers may have already pulled it and built new work on top of it, turning the commit into shared history.

Why changing history after a push is risky

If the commit has become part of public history, overwriting the remote branch can break teammates' local repositories, causing confusing merge, pull, or rebase conflicts.

Is the commit already part of public history?

When the answer may be “yes”, extreme caution is required.

What git push --force actually does

git push --force

replaces the remote history with the local history.

Example:

Remote history: A -- B -- C You reset locally to B and run git push --force. The remote becomes A -- B, and commit C disappears.

If only you used C, the impact is minor. If others have based work on C, their local histories diverge from the remote, leading to messy pulls, merges, and rebases. This is why many teams forbid force‑pushing to main or other shared branches.

A safer alternative: git revert

For collaborative work, the recommended command is:

git revert <commitID>

git revert

does not delete history; it creates a new “inverse” commit that undoes the changes.

Example of a bad commit: + const debug = true After running git revert, a new commit is added: - const debug = true The history now looks like A -- B -- C -- D, where C is the erroneous commit and D is the revert commit. Everyone can pull D and stay in sync without history rewrites.

Core differences between git reset and git revert

reset : rewrites past history; suitable for local, un‑pushed commits.

revert : adds a new commit that undoes a change; suitable for commits that have already been pushed and are shared among multiple developers.

Thus, reset is handy during local development, but for commits already on a shared branch (e.g., main, master, develop) you should prefer revert.

When force‑push may be acceptable

You are working on a personal branch.

No one else has based work on that branch.

The team has agreed that the branch’s history may be rewritten.

You fully understand which commits you will overwrite.

For newcomers, a conservative rule is to avoid force‑pushing to public branches. If a force‑push is unavoidable, confirm with the team first.

Key takeaways

After a push, a commit may already be part of public history. git push --force overwrites remote history and carries high risk in team settings.

For erroneous commits that have been pushed, prefer git revert to create a safe undo commit.