Force "git push" to overwrite remote files

Question

I want to push my local files, and have them on a remote repo, without having to deal with merge conflicts. I just want my local version to have priority over the remote one.

How can I do this with Git?

Adherence

Did git push origin --force not work for you? – Pedestrianize

possible duplicate of Overriding remote git repository with my repository – Endmost

It's unclear if you only want to override the .git files, or the associated working copy. If it's the git repository, git push is the answer. If you want to update the remote working copy, you have to use a post-receive hook – Skutchan

A likely cause, force push does not work is, that it may have been explicitly disabled on the remote repo (to ensure nothing get losts due to idiotic and/or malign contributors): use config receive.denyNonFastforwards to find out. – Stansberry

I tried git push origin some_branch --force but it always returned Everything is up-to-date message. But, git push origin your_branch:some_branch --force and this was what I was missing. Hope it helps! – Bartram

Answer 1

You should be able to force your local revision to the remote repo by using

git push -f <remote> <branch>

(e.g. git push -f origin master). Leaving off <remote> and <branch> will force push all local branches that have set --set-upstream.

Just be warned, if other people are sharing this repository their revision history will conflict with the new one. And if they have any local commits after the point of change they will become invalid.

Update: Thought I would add a side-note. If you are creating changes that others will review, then it's not uncommon to create a branch with those changes and rebase periodically to keep them up-to-date with the main development branch. Just let other developers know this will happen periodically so they'll know what to expect.

Update 2: Because of the increasing number of viewers I'd like to add some additional information on what to do when your upstream does experience a force push.

Say I've cloned your repo and have added a few commits like so:

            D----E  topic
           /
A----B----C         development

But later the development branch is hit with a rebase, which will cause me to receive an error like so when I run git pull:

Unpacking objects: 100% (3/3), done.
From <repo-location>
 * branch            development     -> FETCH_HEAD
Auto-merging <files>
CONFLICT (content): Merge conflict in <locations>
Automatic merge failed; fix conflicts and then commit the result.

Here I could fix the conflicts and commit, but that would leave me with a really ugly commit history:

       C----D----E----F    topic
      /              /
A----B--------------C'  development

It might look enticing to use git pull --force but be careful because that'll leave you with stranded commits:

            D----E   topic

A----B----C'         development

So probably the best option is to do a git pull --rebase. This will require me to resolve any conflicts like before, but for each step instead of committing I'll use git rebase --continue. In the end the commit history will look much better:

            D'---E'  topic
           /
A----B----C'         development

Update 3: You can also use the --force-with-lease option as a "safer" force push, as mentioned by Cupcake in his answer:

Force pushing with a "lease" allows the force push to fail if there are new commits on the remote that you didn't expect (technically, if you haven't fetched them into your remote-tracking branch yet), which is useful if you don't want to accidentally overwrite someone else's commits that you didn't even know about yet, and you just want to overwrite your own:

git push <remote> <branch> --force-with-lease

You can learn more details about how to use --force-with-lease by reading any of the following:

• git push documentation
• Git: How to ignore fast forward and revert origin [branch] to earlier commit?

Sleigh

Since this is the selected answer, I will comment here. Using force isn't a problem when working by yourself. For example, my cloud host starts with it's own git. If I work locally and build a project, and I want to put it on my cloud host (OpenShift), I have two separate git projects. My local and my OpenShift one. I get my local just as I like, but now want to preview it on my OpenShift. You then push to OpenShift for the first time, using -f flag. Essentially putting your local git onto OpenShift. – Viscardi

You can also do git push -f as long as the remote branch you want to push to is the most recent one you pushed to. – Baldwin

"will force push all local branches" - Why would it push anything but the active branch? – Kilk

I tried git push origin some_branch --force but it always returned Everything is up-to-date message. But, git push origin your_branch:some_branch --force and this was what I was missing. Hope it helps! – Bartram

I had the same issue, however currently I am getting this message (github specific): remote: Support for password authentication was removed on August 13, 2021. remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication. – Quirites

Answer 2

You want to force push

What you basically want to do is to force push your local branch, in order to overwrite the remote one.

If you want a more detailed explanation of each of the following commands, then see my details section below. You basically have 4 different options for force pushing with Git:

git push <remote> <branch> -f
git push origin master -f # Example

git push <remote> -f
git push origin -f # Example

git push -f

git push <remote> <branch> --force-with-lease

If you want a more detailed explanation of each command, then see my long answers section below.

Warning: force pushing will overwrite the remote branch with the state of the branch that you're pushing. Make sure that this is what you really want to do before you use it, otherwise you may overwrite commits that you actually want to keep.

Force pushing details

Specifying the remote and branch

You can completely specify specific branches and a remote. The -f flag is the short version of --force

git push <remote> <branch> --force
git push <remote> <branch> -f

Omitting the branch

When the branch is omitted, Git will figure it out based on your config settings. In Git versions after 2.0, a new repo will have default settings to push the currently checked-out branch:

git push <remote> --force

while prior to 2.0, new repos will have default settings to push multiple local branches. The settings in question are the remote.<remote>.push and push.default settings (see below).

Omitting the remote and the branch

When both the remote and the branch are omitted, the behavior of just git push --force is determined by your push.default Git config settings:

git push --force

• As of Git 2.0, the default setting, simple, will basically just push your current branch to its upstream remote counter-part. The remote is determined by the branch's branch.<remote>.remote setting, and defaults to the origin repo otherwise.

• Before Git version 2.0, the default setting, matching, basically just pushes all of your local branches to branches with the same name on the remote (which defaults to origin).

You can read more push.default settings by reading git help config or an online version of the git-config(1) Manual Page.

Force pushing more safely with --force-with-lease

Force pushing with a "lease" allows the force push to fail if there are new commits on the remote that you didn't expect (technically, if you haven't fetched them into your remote-tracking branch yet), which is useful if you don't want to accidentally overwrite someone else's commits that you didn't even know about yet, and you just want to overwrite your own:

git push <remote> <branch> --force-with-lease

You can learn more details about how to use --force-with-lease by reading any of the following:

• git push documentation
• Git: How to ignore fast forward and revert origin [branch] to earlier commit?

Logographic

You're right, but this should really only be used in exceptional situations. – Tatouay

@ScottBerrevoets "I would prefer is to push what I have and let it overwrite remotely rather than integrate." I gave the OP exactly what he asked for. – Logographic

FYI: merged from stackoverflow.com/questions/24768330/… – Insolvable

Answer 3

Another option (to avoid any forced push which can be problematic for other contributors) is to:

• put your new commits in a dedicated branch
• reset your master on origin/master
• merge your dedicated branch to master, always keeping commits from the dedicated branch (meaning creating new revisions on top of master which will mirror your dedicated branch).
  See "git command for making one branch like another" for strategies to simulate a git merge --strategy=theirs.

That way, you can push master to remote without having to force anything.

Hoo

How does the result differ from "push -force"? – Lozoya

@Lozoya Any forced push would rewrite the history, forcing other users of the repo to reset their own local repo to match the newly pushed commits. This approach only creates new commits and does not require a forced push. – Hoo

Answer 4

Works for me:

git push --set-upstream <remote> <branch> -f

Venturous

Answer 5

git push -f is a bit destructive because it resets any remote changes that had been made by anyone else on the team. A safer option is

git push --force-with-lease

What --force-with-lease does is refuse to update a branch unless it is the state that we expect; i.e. nobody has updated the branch upstream. In practice this works by checking that the upstream ref is what we expect, because refs are hashes, and implicitly encode the chain of parents into their value.

You can tell --force-with-lease exactly what to check for, but by default will check the current remote ref. What this means in practice is that when Alice updates her branch and pushes it up to the remote repository, the ref pointing head of the branch will be updated. Now, unless Bob does a pull from the remote, his local reference to the remote will be out of date. When he goes to push using --force-with-lease, git will check the local ref against the new remote and refuse to force the push. --force-with-lease effectively only allows you to force-push if no-one else has pushed changes up to the remote in the interim. It's --force with the seatbelt on.

Nous

Answer 6

// make sure your local branch is up to date
git checkout fix-build
git pull origin fix-build

// push your local branch to overwrite remote branch 'main'
git push -f origin fix-build:main

ps. The accepted answer did not work for me. I am not sure if it is due to Git version.

Dianthus