How do I properly force a Git push?
Solution 1
Just do:
git push origin <your_branch_name> --force
or if you have a specific repo:
git push https://git.... --force
This will delete your previous commit(s) and push your current one.
It may not be proper, but if anyone stumbles upon this page, thought they might want a simple solution...
Short flag
Also note that -f
is short for --force
, so
git push origin <your_branch_name> -f
will also work.
Solution 2
And if push --force
doesn't work you can do push --delete
. Look at 2nd line on this instance:
git reset --hard HEAD~3 # reset current branch to 3 commits ago
git push origin master --delete # do a very very bad bad thing
git push origin master # regular push
But beware...
Never ever go back on a public git history!
In other words:
- Don't ever
force
push on a public repository. - Don't do this or anything that can break someone's
pull
. - Don't ever
reset
orrewrite
history in a repo someone might have already pulled.
Of course there are exceptionally rare exceptions even to this rule, but in most cases it's not needed to do it and it will generate problems to everyone else.
Do a revert instead.
And always be careful with what you push to a public repo. Reverting:
git revert -n HEAD~3..HEAD # prepare a new commit reverting last 3 commits
git commit -m "sorry - revert last 3 commits because I was not careful"
git push origin master # regular push
In effect, both origin HEADs (from the revert and from the evil reset) will contain the same files.
edit to add updated info and more arguments around push --force
Consider pushing force with lease instead of push, but still prefer revert
Another problem push --force
may bring is when someone push anything before you do, but after you've already fetched. If you push force your rebased version now you will replace work from others.
git push --force-with-lease
introduced in the git 1.8.5 (thanks to @VonC comment on the question) tries to address this specific issue. Basically, it will bring an error and not push if the remote was modified since your latest fetch.
This is good if you're really sure a push --force
is needed, but still want to prevent more problems. I'd go as far to say it should be the default push --force
behaviour. But it's still far from being an excuse to force a push
. People who fetched before your rebase will still have lots of troubles, which could be easily avoided if you had reverted instead.
And since we're talking about git --push
instances...
Why would anyone want to force push?
@linquize brought a good push force example on the comments: sensitive data. You've wrongly leaked data that shouldn't be pushed. If you're fast enough, you can "fix"*
it by forcing a push on top.
*
The data will still be on the remote unless you also do a garbage collect, or clean it somehow. There is also the obvious potential for it to be spread by others who'd fetched it already, but you get the idea.
Solution 3
If I'm on my local branch A, and I want to force push local branch B to the origin branch C I can use the following syntax:
git push --force origin B:C
Solution 4
use this following command:
git push -f origin master
Solution 5
First of all, I would not make any changes directly in the "main" repo. If you really want to have a "main" repo, then you should only push to it, never change it directly.
Regarding the error you are getting, have you tried git pull
from your local repo, and then git push
to the main repo? What you are currently doing (if I understood it well) is forcing the push and then losing your changes in the "main" repo. You should merge the changes locally first.
Spyros
Updated on May 12, 2022Comments
-
Spyros about 2 years
I've set up a remote non-bare "main" repo and cloned it to my computer. I made some local changes, updated my local repository, and pushed the changes back to my remote repo. Things were fine up to that point.
Now, I had to change something in the remote repo. Then I changed something in my local repo. I realized that the change to the remote repo was not needed. So I tried to
git push
from my local repo to my remote repo, but I got an error like:To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of
git push --help
for details.I thought that probably a
git push --force
would force my local copy to push changes to the remote one and make it the same. It does force the update, but when I go back to the remote repo and make a commit, I notice that the files contain outdated changes (ones that the main remote repo previously had).
As I mentioned in the comments to one of the answers:
[I] tried forcing, but when going back to master server to save the changes, i get outdated staging. Thus, when i commit the repositories are not the same. And when i try to use git push again, i get the same error.
How can I fix this issue?
-
VonC almost 11 yearsYou will soon (git1.8.5, Q4 2013) be able to do a
git push -force
more carefully. -
Admin almost 10 years
-
Admin almost 10 yearsAs I detail in my own answer,
git push --force
is indeed another valid way to force push, and will push branches just as well asgit push origin master --force
with Git's defaultpush.default config settings
, though which branches specifically get pushed differs between Git versions prior to 2.0 versus after 2.0. -
rogerdpack about 6 years
git push --force
works fine these days, FWIW... -
spoorcc over 5 years
git push --force-with-lease
works even better :), it will refuse to update a branch unless it is the state that you expect. (see developer.atlassian.com/blog/2015/04/force-with-lease) -
Sumit over 3 yearsjust be careful folks > When you force push code to the master branch [remote repo] it deletes the previous code present in the master branch . > and force update your code with the previous code. i.e when you force push previous code will bereplace by your code. [check out this blog for more info ](evilmartians.com/chronicles/…) Happy Coding :)
-
-
Spyros about 13 yearsyes i tried a pull but i'm losing losing data because of that pull. I want to make my main repos as my local is, without first updating from the main.
-
ubik about 13 yearsIn that case use
git push -f
, but then if you change your main repo again, you have to go back to your local repo andgit pull
, so that it gets in sync with the latest changes. Then you can do your work, and push again. If you follow this "push-pull" workflow, you won't get the kind of error you were complaining about. -
Spyros about 13 yearsyeah, i understand that this was my fault :/ I will try that and get back in a little while thanx
-
Spyros about 13 yearstried forcing, but when going back to master server to save the changes, i get outdated staging. Thus, when i commit the repositories are not the same. And when i try to use git push again, i get the same error.
-
rogerdpack almost 11 yearsLooks like it's possible to do a pull after this, but hard stackoverflow.com/questions/9813816/…
-
cregox almost 11 yearsThe problem, @rogerdpack, isn't if it's doable. It is. But it can sum up to a big disaster. The more someone do it (force push) and the less often you update (pull) from the public repo, the bigger the disaster. It can dismantle the world as you know it!!!111 At least the world comprising of that particular repository.
-
nickgrim over 10 yearsYou can use
git push origin +master
instead, which allow you push multiple refspecs without forcing them all. -
linquize over 10 yearsIf you have sensitive data, force push it
-
cregox over 10 years@linquize not following. I'd say if you have sensitive data, revert it.
-
Stuart Golodetz over 10 years@Cawas: I think he means that if you are trying to remove sensitive data from the repository, then you want to rewrite history. If you revert, the sensitive data is still there in the earlier commit. That said, if someone else has already pulled from the repository, then rewriting history won't help you prevent them from accessing the sensitive data - it's already too late at that point.
-
cregox over 10 years@StuartGolodetz thanks for clarifying! I completely misinterpreted "sensitive" there - I was thinking just "important" and not "classified".
-
Can Poyrazoğlu over 10 years
git push origin master --delete # do a very very bad bad thing git push origin master # regular push
this actually solved my problem perfectly (on a repo with only me and my friend). maybe it's wrong for public repos but for a private one this is a life saver. -
Jeewes almost 10 yearsBe aware that, if you accidentally do just
git push --force
, you might end up messing you master branch (depending on your push default behavior).. Which might suck.. a bit.. :D -
Admin almost 10 years@Jeewes starting with Git version 2.0, the default behavior of
git push --force
is basically to force push the currently checked-out branch to its remote-counter part, so if you have the master branch checked out, then it's identical togit push origin master --force
. It'll be different if you're using thematching
setting forpush.default
, which is the default for Git versions prior to 2.0.matching
pushes all locals branches to remote ones that have the same name, so force pushing then could definitely be not what you want to do... -
Admin almost 10 years@Jeewes But with Git 2.0, the default is safer, or at least it's no more dangerous than
git push origin master --force
is. -
Joe about 9 yearsThere is also the case that you are not pushing to a public server. You are pushing to some other repo to build on a dev box or something, and no one is interested in the old version of your work.
-
Weishi Z over 8 yearsI found out that even I'm on my local branch B, I still need to do
git push --force origin B:C
. In my case, it seems thatgit push --force origin C
will only push from local master to remote C branch, regardless of which branch I'm currently on.git version 2.3.8 (Apple Git-58)
-
Peter Krauss over 8 yearsOops, not worked for mee (!), but I used
git push -f
, is not the same?? See (need to correct?) stackoverflow.com/a/10728449/287948 -
Abhishek about 8 yearsWhy would anyone want to force push? May be someone has made a commit that you want to discard completely. stackoverflow.com/questions/37132584/…
-
mihai about 8 yearspush -f is good but not recoomended for master since most corporate repositories have -f disabled for master. the
merge -s ours
worked for me -
Adam about 7 yearsMaybe give some more explanation about why this answer is preferable to the other ones, and what makes it different.
-
mustafa Elsayed about 7 yearsoh ,sorry for inconvenience , I was having the same problem and this command solve it , i thought i should share it .
-
svelandiag about 7 yearsIt's just the same as the others, you just changed the position of the
-f
flag... -
Autumn Leonard about 7 yearsMore generally:
git push -f <remote> <branch>
-
chovy over 5 yearsunfortunately on gitlab you will still have old history.
-
FlavorScape over 5 yearsthis happens automatically with some repo managers, a.k.a. auto-squash etc. force pushing after finishing a feature branch to reduce commits is common and expected.
-
LargeDachshund about 3 yearsDon't forget that your remote repo permissions (read: Azure DevOps) for your account, might not grant permission to force push. In that case, you'll need an administrator to set your permissions.
-
hd1 almost 3 yearsCan you even push to a non-bare git repository?
-
VonC almost 3 years@hd1 Yes, since Git 2.4 (Q2 2015): stackoverflow.com/a/42745909/6309, which references stackoverflow.com/a/34575157/6309.
-
Ícaro over 2 yearsThis helped me when moving a repository from the previous
master
branch to the newmain
branch. Just usedmaster:main
and it worked as I needed! -
openCivilisation about 2 years--force-with-lease is a better option because it will not push if the state of the remote has changed since the last pull
-
Eric Aya about 2 yearsThis has already been mentioned in several other answers.