Error "Updates were rejected because the remote contains work that you do not have locally"

Question

I'm working on a team with a few developers using Git on Bitbucket. We are all working on a dev branch, not pushing to master until a release.

One of the developers committed incorrect code that overwrote my own by accident, and now I am trying to push the correct code back to the repository. I have been reading about this error for a few days now, and I can't push to the repository any more, because I am getting the following error:

 ! [rejected]        master -> dev (fetch first)
error: failed to push some refs to 'https://[email protected]/repo_user/repo_name.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I follow the instructions and pull, but then I receive a merge conflict. After entering a message for the merge conflict, my local code is now the incorrect code that the other developer uploaded by accident (as expected from the pull). So I replace the incorrect code with the backup I copied before committing, and when I try to push again, I get the same error.

How can I solve this issue?

These are the commands I run in order to commit:

git pull remotename master:dev
git add --all
git commit -m "some message"
git pull remotename master:dev
git push remotename master:dev

I would have thought that if I kept this order, I would not receive merge conflicts. I guess I was wrong.

I have looked for a few hours on Google and Stack Overflow, and followed different instructions, but I still can't do a Git push to the dev branch.

Didactic

this same error message is shown when you issue git push when currently in dir from another repo .... the git message should get updated to reflect this especially since its tone sounds so authoritative one might be convinced otherwise – Langford

Answer 1

git pull <remote> master:dev will fetch the remote/master branch and merge it into your local/dev branch.

git pull <remote> dev will fetch the remote/dev branch, and merge it into your current branch.

I think you said the conflicting commit is on remote/dev, so that is the branch you probably intended to fetch and merge.

In that case, you weren't actually merging the conflict into your local branch, which is sort of weird since you said you saw the incorrect code in your working copy. You might want to check what is going on in remote/master.

Bulletin

Wow...I never knew that. But it makes a lot of sense now. The master branch was also incorrect, so your answer clears my whole question. I'm still a bit new to git. Thanks a lot for telling me the difference between those two! – Didactic

Best option for me was git pull --rebase. – Nawrocki

git pull <remote> master:dev What is dev here ? – Amortizement

Answer 2

You can override any checks that Git does by using "force push". Use this command in the terminal:

git push -f origin master

However, you will potentially ignore the existing work that is in remote. You are effectively rewriting the remote's history to be exactly like your local copy.

Tenantry

Using force push (-f) flag is very dangerous and it should never be part of your regular work flow – Fumikofumitory

Downvoted since I’m missing some warning in this answer. – Ania

Ooh! This force the repository to rewrite itself. – Lialiabilities

Yeah this saved me since I didn't need anything in the existing repo, but definitely a scary command – Hollar

I had the same error with github and I fixed it with this command, @theeastcoastwest why are you saying this is dangerous? what is your reason" – Pariah

@Pariah this is dangerous because it ignores the work that is in remote and it forces your changes onto the repo. So if you don't want to mess up your team's work, DO NOT force push. – Lydgate

Raise your hand if you did this and feel guilty but would do it again. – Lareine

This command helped me to escape the situation, but I will never use this command. ;) Thank you by the way. upvoted – Afield

@Tenantry Please consider editing in a warning in this answer. git push -force is evil – Dustindustman

this is the only solution when you want to initially push a repository, but you get errors. should be done only once though. – Pardew

Agree with Spaideri's comment (because this is not a normal process especially when working on a repo with others AND because warnings provided by others in this very comment list) but occasionally on a brand new repo init, this can be helpful. – Ology

I get an error: error: src refspec master does not match any error: failed to push some refs to – Likely

Nothing wrong with using -f when initializing a newly created repository. Just make sure you know what you do when using -f on the existing repository. – Wack

To moderator: I got pinged by Stack Overflow and automatically assumed this was my answer. I do not know why that happened. Please ignore my comment and my flag. – Orsola

True but dangerous – Spiderwort

it will remove all the old commits. – Clari

Sad, I lost my 162 commit by this. I don't know much about git as I only edit them from my browser, I tried git command line and this happen :( – Deuced

I have no choice but force it because git cant handle the issue – Tusk

For those who are not pushing to master, just use: git push -f – Ganges

Answer 3

It happens when we are trying to push to remote repository but has created a new file on remote which has not been pulled yet, let say Readme. In that case as the error says

git rejects the update

as we have not taken updated remote in our local environment. So Take pull first from remote

git pull

It will update your local repository and add a new Readme file. Then Push updated changes to remote

git push origin master

Diaeresis

I was doing git pull origin develop into my local develop branch, but now, just doing git pull it works fine to me, I dunno why. – Brennan

because by default if your local branch is synched with remote branch and you are checked out in that branch you don't need to specify a branch just git pull is enough – Diaeresis

git pull helps – Amortizement

Answer 4

This usually happens when the repo contains some items that are not there locally. So in order to push our changes, in this case we need to integrate the remote changes and then push.

So create a pull from remote

git pull origin master

Then push changes to that remote

git push origin master

Maurizio

Error: fatal: refusing to merge unrelated histories – Likely

Answer 5

You can try this: git pull origin master --rebase

Tyrothricin

Hi Eduardo! This worked for me. But can you explain why it works? What does this command do exactly? – Stoneman

After add manually file README.md on site GitHub. I also can't push project from device to Git like normally. Your anwser helped me so much!!!! Thanks bro <3 – Mercurialize

Answer 6

You need to input:

git pull
git fetch 
git merge

If you use a git push origin master --force, you will have a big problem.

Sherfield

Why do you need to use git fetch and git merge again manually after running git pull which contains them? – Ania

Answer 7

Force to push

git push -f origin master

Asset

This should probably come with a warning. – Inexpiable

Even if this surely will work, would you mind explaining it? Could there possibly be any danger in doing this? If yes, explain that even further, like: "Folks, be sure that you will loose commits using this" – Culm

Answer 8

This is how I solved this issue:

1. git pull origin master
2. git push origin master

This usually happens when your remote branch is not updated. And after this if you get an error like "Please enter a commit message" Refer to this ( For me xiaohu Wang answer worked :) )

Berky

There isn't anyone with the name "xiaohu Wang" here, not even close (and not in deleted answers either). What answer does it refer to? – Because

@Peter Mortensen he refers to an answer you can find by clicking the link – Disputation

Answer 9

I fixed it, but I'm not exactly sure what I did. I tried simply pushing and pulling using:

git pull <remote> dev instead of git pull <remote> master:dev

Didactic

Answer 10

git pull --rebase origin master

git push origin master

---

git push -f origin master

Warning git push -f origin master

• forcefully pushes on existing repository and also delete previous repositories so if you don`t need previous versions than this might be helpful

Hendrik

Answer 11

Well actually github is much simpler than we think and absolutely it happens whenever we try to push even after we explicitly inserted some files in our git repository so, in order to fix the issue simply try..

: git pull

and then..

: git push

Note: if you accidently stuck in vim editor after pulling your repository than don't worry just close vim editor and try push :)

Laudianism

Answer 12

I have done below steps. finally it's working fine.

Steps

1) git init

2) git status (for checking status)

3) git add . (add all the change file (.))

4) git commit -m "<pass your comment>"

5) git remote add origin "<pass your project clone url>"

6) git pull --allow-unrelated-histories "<pass your project clone url>" master

7) git push -u "<pass your project clone url>" master

Needful

Answer 13

The best option for me and it works and simple

git pull --rebase

then

git push

best of luck

Breathy

Answer 14

You can use

git pull --rebase <your_repository_name> <your_branch>

This will help in case you have some changes not yet registered in your local repository, especially README.md.

Daven

Answer 15

If you have initialized a new GitHub repository with a ReadMe file and have also received a fatal error like this:

fatal: refusing to merge unrelated histories

then you probably wanted to try the command below:

git pull origin master --allow-unrelated-histories

Now you can try pushing your project to your new repository:

git push origin [branch]

Note: If you have an initialized repository in GitHub and also committed locally, then you need to use the suggested command above, the first command "git pull origin...". Otherwise, you can simply type the following command:

git pull origin [branch]

Caravansary

Answer 16

I had this error and it was because there was an update on the server, but Sourcetree was not showing any updates available (possibly because I was offline when it last checked). So I did a refresh in source tree and now it shows two items to push instead of 1 item.

So be sure to press refresh or pull if you get this error and then try again.

Overbear

Answer 17

The error possibly comes because of the different structure of the code that you are committing and that is present on GitHub. You may refer to: How to deal with "refusing to merge unrelated histories" error:

git pull --allow-unrelated-histories
git push -f origin master

Subcritical

Even if this surely will work, would you mind explaining it? Could there possibly be any danger in doing this? If yes, explain that even further, like: "Folks, be sure that you will loose commits using this" – Culm

Answer 18

I had the same problem. It happened that I had created a .Readme file on the repository without pulling it first.

You may want to delete the .Readme file or pull it before pushing.

Shoebill

I'm not sure this answer to a 5year old question provides any additional value, plus It does not provide a solution to the specific problem of the OP. Since you're a new contributor, please take a look at a guide on how to answer questions: stackoverflow.com/help/how-to-answer – Greyhound

Please explain further why adding a readme file should lead to the given error message – Culm

Answer 19

I had the same problem. Make sure that you are on the right Heroku account.

It appeared when I tried to push the changes to the wrong Heroku account.

Aletaaletha

Answer 20

1. git pull origin

2. Accept the changes depending upon your requirement, like keeping incoming or keeping existing changes.

3. git add . Else issue git add.

4. git commit -m "keep your commit message"

5. git push origin

This has worked to me.

Dexterous

Answer 21

You could simply and safely revert the changes made by your colleague using the git revert command.

git revert commit-hash

The SHA-1 hash value can be found with the following command.

git log

It's not ideal to revert a commit. In fact, it is a really rare case to do so. What happens often is that developers would work concurrently on similar files and do changes that were divergent. Git is built in order to mitigate the amount of effort required to maintain a healthy codebase.

On top of Git, services like GitHub, Bitbucket, GitLab and possibly others provide handy interfaces and feature to reduce even more issues like that.

Preventing a direct push to a shared branch for example and replacing them by pull request (PR) using sub-branches instead.

If you're a team lacking a little organization, my suggestion for you is to work faster in order to push breaking changes before others. (jk)

Enough of my monologue. There are a few methods that I like to use when this problem occurs.

First, and obvious one, try to fix the conflict before pushing your changes. IDEs nowadays have really nice interface for conflicts. This is an example in Visual Studio Code:

There are a couple of apparent buttons, "Accept current, incoming, both" which will let you select which piece of code you want to keep, modify or remove. You can also edit the code manually if you wish! Without the IDE consent of course.

This is great, for when your work is in progress and you actually need the changes made by your teammates. Or when you're done and you just want to land a PR before heading to bed after your third overtime.

You could do the same things via the commandline, but you might end up bald by the end of the process.

If you're working on a large feature and you've done lots of changes, but you want to keep your files uncommitted, because it's handy sometimes to do so. Stashing is your friend:

git stash > Will temporary store your changes locally until you do a
git stash pop >  which will retrieve and apply the changes for you.

Pulling a branch in between stash operations will not trigger a conflict, assuming your branch is close to the shared one. Otherwise, you're back at step one.

My third and final little secret are diff files:

git checkout -b branch_a
git diff dev..branch_a > changes.diff
git apply changes.diff

Basically, it compares the difference between two branches and creates a file called changes.diff. It will show all the changes made by your colleague and will help you decide what to keep or remove

Btw! you can do a merge --abort to cancel m.

Cochineal