Git Push Force: How it Works and How to Use it Safely

You probably have experienced this as a developer: You just realized your code had an issue in your last commit. To undo this mistake, you run some commands and rewrite your local history. When you run git push --force to clean everything up, your teammates notify you that some commits are missing or your pipeline has broken builds.

In this article, I will walk you through what git push --force actually does, when to use it, and how to avoid errors. If you are getting started with Git, I recommend taking our Introduction to Git course to learn about version control. Also, I find the Git Cheat Sheet, which you can download, is a helpful reference because it has all the most common Git terminologies and commands.

When You Might Think You Need git push --force

Let’s say you’re cleaning up your local commit history before pushing your work. To tidy up your commit history before merging, you run git rebase -i main. Everything looks perfect locally, so you try to update your remote branch with a simple git push. But instead of the usual success message, Git shows you an error.

You may encounter another situation where you accidentally commit sensitive data, maybe an API key or password, and push it to the remote. After rewriting history locally to remove the offending commit, you find that a normal push doesn’t update the remote repository, and the sensitive data remains. You get an error message instead.

! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.,
hint: 'git pull ...') before pushing again.

This “non-fast-forward” error is Git’s safety net, which is a warning that something about your history doesn’t match what’s on the server. At this point, it’s tempting to run git push --force to bypass this error.

That may work fine if you’re the only one working on the branch. However, shared projects can easily create confusion or delete someone else’s work.

What git push --force Actually Does

Usually, Git only lets you push your changes if your local branch contains everything that’s already on the remote, including your new commits. However, sometimes you may rewrite your commit history through git rebase, squashing, or removing sensitive data. When you do this, your local branch will be different from the remote branch. Then as you try to push a new commit, Git shows the error, which protects the remote branch from loss of work.

Using git push --force tells Git to skip the safety check and overwrite the remote branch with what is in your local branch. 

Here’s what that looks like:

git push --force origin main

This will update the remote's main branch to match your local main and delete any commits that aren't in your local branch. 

Now, picture your Git branch like a chapter in a shared book that your team is writing together. A standard push is like adding new paragraphs at the end of the chapter. However, a git push --force is more powerful and rips out the current chapter and replaces it entirely with your version. 

The risk of using git push --force is that collaborators may lose work if they base their changes on the commits you just wiped out. In the next section, we will look at the precautions to take when working with the  --force command.

Why This Can Break Everything for Your Team

If you forcefully push your changes to a shared branch like main or develop, you are likely to experience the following:

• Others' local branches get out of sync: If your teammates have pulled the old commits that you’ve now erased from the remote, their local histories no longer match the server. Their branches will reference commits that have “disappeared,” creating confusion and 
• Pulling results in confusing merges or errors: When someone tries to git pull after you’ve force-pushed, Git won’t know how to reconcile the rewritten history with their local sequence of commits. This often leads to odd merge commits, cryptic errors, or situations where teammates are told to manually intervene with git fetch, git reset, or even re-clone the branch.
• CI/CD pipelines may fail: Pipelines often rely on consistent commit hashes and linear history. A force push can cause them to fail tests, redeploy incorrect code, or crash when rebuilding on outdated commits.

Check out our CI/CD for Machine Learning course to understand how to build CI/CD workflows. I also recommend taking our Introduction to Data Versioning with DVC course to learn the difference between data versioning and code versioning.

Let me illustrate this: You're on the feature branch with a teammate. You clean your local history, then run git push --force. Minutes later, your teammate pushes their changes. They see errors in Git. When they pull, they get merge conflicts and a mangled commit history. Meanwhile, your CI pipeline fails due to missing commits. Now, your teammate wastes time untangling the branch, and deployment is delayed.

One force push triggers all of that.

The Safer Option: git push --force-with-lease

To avoid such issues, I recommend using git push --force-with-lease. This command adds a safety check when pushing to a remote branch to avoid unexpected commits.

git push --force-with-lease origin main

Think of --force-with-lease like “asking if the coast is clear before jumping in”. Before it does anything, it makes sure no one else has changed the branch. If everything’s as you last saw it, your history is updated. But if there are new changes you didn’t know about, Git stops you and prompts you to review the situation first. Thus, this command will always protect collaborators from unintended overwriting.

How to Recover from a Bad Force Push

If you lose some commits, don’t worry because you can still recover them. Git always keeps a record of changes to the current commit, including rewrites, and stores it in the reflog.

Here’s how you can recover lost commits:

Step 1: Use git reflog to find lost commits

Run git reflog to view your branch history.

git reflog

You may see your commits like this:

abc1234 HEAD@{1}: push: force push
def5678 HEAD@{2}: commit: add new feature

Step 2: Restore the lost commit

When you’ve identified the commit hash you want to recover, use the command below to get to the specific branch.

git checkout def5678

Step 3: Create a new branch

To safely recover the files, create a new git branch.

git checkout -b recovery-branch

Step 4: Restore the remote branch

Now push the recovered commits to the branch:

git push origin recovery-branch

Keep in mind that reflog data exists only on local machines. Therefore, you may not recover lost commits if none of your teammates had stored them in the local environment.

I recommend taking our Intermediate Git course to learn more about collaboration and working with branches in Git.

Best Practices for Using git push --force Safely

To reduce the chance of breaking things, here are some good habits to follow:

• Prefer --force-with-lease over --force:  This method is a safer option that checks if the remote branch hasn’t changed since your last fetch. I will help to protect your teammates from accidental overwrites.

• Avoid force-pushing to shared branches: Never force-push to shared branches like main, master, develop, or release branches. Only force push to your feature branches where you’re the only contributor to avoid disruption.

• Notify your team before force-pushing: If you must force-push to a shared branch, let your team know. This will allow them to save their work and avoid loss.

• Use protected branches: You can also enable protection for your branches when using platforms like GitHub, GitLab, and Bitbucket. This restricts direct edits and prevents accidental force pushes to important branches.

If you want to learn more about managing private repos, check out our Introduction to GitHub Concepts course to understand how to review pull requests when collaborating on GitHub.

Conclusion

git push --force offers a useful method for rewriting your repo’s history, whether you want to clean commits or remove sensitive data. Always take caution when using this command to avoid breaking your team’s workflow.

Whenever possible, use --force-with-lease instead. It gives you more control without risking other people’s work. With some care and communication, you can keep your Git history clean without causing trouble for your team.

I recommend you check out our Git Fundamentals and GitHub Foundations skills tracks to become an expert in all things Git.