783

I met some issue when I was trying to push my code to GitHub.

Pushing to [email protected]:519ebayproject/519ebayproject.git
To [email protected]:519ebayproject/519ebayproject.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to '[email protected]:519ebayproject/519ebayproject.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I have not pushed anything in the repository yet, so why do I need to pull something?

11
  • 6
    Note that this can also happen for branches previously visited locally, which have had commits in the upstream repository. Is there an easy way to just fast forward such an old branch or simply let git forget about it in the local repository? Commented Feb 19, 2013 at 9:27
  • 53
    @ThorbjørnRavnAndersen - I managed to fix this scenario using 'git push -f' which seemed to make git forget about its imaginary problems :)
    – Echelon
    Commented May 28, 2013 at 14:37
  • 8
    Seen a complain about this from git newcomer. The reason is that when they create a new project on GitHub, they leave tickbox "Initialise with readme" or choose .gitignore/GPL options, so new project already has a commit they do not have locally, thus the confusion caused by error above. Commented Oct 14, 2013 at 14:30
  • 5
    @Echelon the -f option to force the push is dangerous. I just used it in a team project and 6 commits were "striped", simply deleted from server and no way to get them back!
    – Deleplace
    Commented Jan 14, 2014 at 10:47
  • 45
    Its trendy to praise git. But almost every developer I talked to, privately agree that they personally hate git. Now that they use git they spend so much more time in source control compared to what they used to spend when they used perforce or TFS. Commented Mar 5, 2015 at 16:26

31 Answers 31

783

This can cause the remote repository to lose commits; use it with care.

If you do not wish to merge the remote branch into your local branch (see differences with git diff), and want to do a force push, use the push command with -f

git push -f origin <branch>

where origin is the name of your remote repo.

Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This flag disables the check. This can cause the remote repository to lose commits; use it with care.

5
  • 1
    This worked for me for a repo that I have on Github but, I had a submodule from Heroku within my app. and I had to bring the files out of the submodule and then push the updated app to Heroku.
    – JGallardo
    Commented Nov 14, 2013 at 22:37
  • 27
    Make sure you read the last line of the comment on this post! "This can cause the remote repository to lose commits; use it with care." Doing force pushes in a team environment is a dangerous thing, and typically should be avoided. Commented Apr 29, 2014 at 16:07
  • This can also ADD all the history from the original repository to the remote using cherry-pick to move 'just' one commit across. Restore from backup required... Commented Aug 9, 2016 at 14:56
  • It's also worth mentioning that if you are using Github, this may override an open Pull Request you previously created with your most recent commits. From Github Docs: "Force pushing can corrupt your pull request".
    – Armfoot
    Commented Jul 17, 2017 at 11:40
  • This worked for me. I have tried $ git pull origin master -v but it gives error fatal: refusing to merge unrelated histories. Then I tried this and it worked and my local files appeared on github remote repo.
    – G_real
    Commented Aug 23, 2019 at 15:42
247

As the message tells you,

Merge the remote changes (e.g. 'git pull')

Use git pull to pull the latest changes from the remote repository to your local repository. In this case, pulling changes will require a merge because you have made changes to your local repository.

I'll provide an example and a picture to explain. Let's assume your last pull from origin/branch was at Commit B. You have completed and committed some work (Commit C). At the same time, someone else has completed their work and pushed it to origin/branch (Commit D). There will need to be a merge between these two branches.

local branch:                         --- Commit C 
                                    /
                                   /
                                  /
origin/branch: Commit A ------ Commit B ---- Commit D

Because you are the one that wants to push, Git forces you to perform the merge. To do so, you must first pull the changes from origin/branch.

local branch:                         --- Commit C -- Commit E
                                    /               /           
                                   /               /             
                                  /               /               
origin/branch: Commit A ------ Commit B ---- Commit D 

After completing the merge, you will now be allowed to fast-forward origin/branch to Commit E by pushing your changes.

Git requires that you handle merges yourself, because a merge may lead to conflicts.

7
  • 7
    What if you don't want to merge? And just leave D as a side-branch (at least for now). Later, I might commit more after C; someone else might commit more after D. What's the hurry to merge? How can I push a side-branch without merging? ~~~ Commented Nov 26, 2012 at 17:43
  • 3
    local/branch and origin/branch are meant to represent the same branch but on different machines (local vs origin); to push local/branch is to update origin/branch. If you want the state of your branch to be visible to others (ie on origin) but you do not want to merge with origin/branch, then you should create a new branch off of local/branch (git branch [name]) and push that branch to origin (git push -u origin [name]) Commented Nov 27, 2012 at 18:40
  • 1
    Great explanation. This video shows a brief demonstration of the issue and how to resolve it as @JakeGreene describes, as well as two ways to avoid it in the first place when setting up a new repository. Commented Oct 26, 2014 at 17:45
  • 4
    some years later, it just seems that this answer is very very similar to this other
    – superjos
    Commented Aug 12, 2015 at 13:03
  • 1
    For me git pull also printed Already up-to-date. Turned out I was not on the branch i though I was, but a detached HEAD branch (possibly from a failed merge?). This was obvious after running git branch. After running git checkout mybranch everything worked as expected.
    – strider
    Commented Oct 6, 2018 at 23:54
202

Have you updated your code before pushing?

Use git pull origin master before you push anything.

I assume that you are using origin as a name for your remote.

You need to pull before push, to make your local repository up-to-date before you push something (just in case someone else has already updated code on github.com). This helps in resolving conflicts locally.

7
  • 1
    How can I know the repository name? When I type git pull origin master git complains that 'origin' does not appear to be a git repository
    – Ziyuan
    Commented Dec 17, 2012 at 5:16
  • 3
    'origin' is a remote. You can use git remote --verbose to see all the remote configured under your git folder. The information shown on screen will also include either "[email protected]" paths or HTTPS paths, from which you should be able to identify where to push. Hope this helps !
    – AYK
    Commented Dec 17, 2012 at 5:38
  • 17
    git pull origin master showing Already up-to-date. but then when try to push on origin_branch this say same warning mentioned in question. Any suggestion !!
    – CoDe
    Commented Apr 20, 2016 at 13:04
  • 2
    @Shubh did you ever solve the issue? Im getting the same thing! Commented May 3, 2016 at 7:15
  • 3
    @OriginalAlchemist yes..since I'm only developer who working on remote-local branch...so I did force push local branch ..and that override all changes of open branch on server with my changes from local system. git push -f <remote> <branch> e.g. git push origin <your_local_branch> check this thread.
    – CoDe
    Commented May 3, 2016 at 10:03
127

This normally happens when you git commit and try to git push changes before git pulling on that branch x where someone else has already made changes.

The normal flow would be as below,

STEP 1: git stash your local uncommitted changes on that branch.

STEP 2: git pull origin branch_name -v to pull and merge to locally committed changes on that branch (give this merge some message, and fix conflicts if any.)

STEP 3: git stash pop the stashed changes (Then you can make commits on popped files if you want or push already committed changes (STEP4) first and make new commit to files later.)

STEP 4: git push origin branch_name -v the merged changes.

Replace branch_name with master (for master branch).

2
  • 4
    where is the commit? Should you not commit your changes after stash pop?
    – mehmet
    Commented May 18, 2016 at 19:38
  • I should. I generally push the merged code first and then commit my local uncommited changes. You can commit and push at once as well. Just preference. Commented Oct 18, 2017 at 18:33
63

First and simple solution:

  • Try this command git push -f origin master.
  • This command will forcefully overwrite remote repository (GitHub)

Recommended Solution 1 :

  • Run these commands:
git pull --allow-unrelated-histories  //this might give you error but nothing to worry, next cmd will fix it
git add *
git commit -m "commit message"
git push

If this doesn't work then follow along 🔰

Solution 2 (Not Recommend) :

Will Delete all your & your team-mate's commit history. So please dont do this on professional project

  • Delete .git directory from the folder.

  • Then execute these commands:

      git init
      git add .
      git commit -m "First Commit"
      git remote add origin [url]
      git push -u origin master
    

OR

git push -f origin master 

Only use git push -f origin master if -u dont work for you.

As you might have guessed, manipulating master is not a good thing. So simply replace it with the branch name you want to work on. Or create a new one git checkout -b fix-something

3
  • 6
    Deleting your git repo and losing your entire commit history is a "Recommended" solution? Seems hasty. Commented Feb 4, 2019 at 14:14
  • @Nils Guillermin It depends on your situation. If i am working on a large project where I have to fix all the merge conflicts then I would use vscode to review and merge all changes easily. Thanks for your opinion though.
    – primegxy
    Commented Apr 27, 2019 at 2:56
  • 1
    This answer is so harmful and should be removed. Don't ever suggest to delete a .git directory, and force pushing should never be done on a master branch. Commented Aug 16, 2020 at 2:18
50

Sometimes we forgot the pulling and did lots of works in the local environment.

If someone want to push without pull,

git push --force

is working. This is not recommended when working with other people, but when your work is a simple thing or a personal toy project, it will be a quick solution.

3
  • $git push --force origin master Commented Oct 3, 2017 at 17:21
  • 2
    This worked for me: personal project with 0 other collaborators. I had tried several other suggested "solutions" here on SO, none of which fixed what was a very simple problem: I had done a local reset --hard to a older commit and then done a couple more. Then I just wanted to push but the remote repo was not prepared to let me. WarrenP could actually help git learners by being less runic. Maybe he doesn't want to. Commented Nov 19, 2017 at 15:28
  • 3
    Either don't use it, or learn to use it right. If you force push to an important central repository shared by a team, you should lose all push access to all important repos. What you do on your own personal repo, to avoid learning the alternative ways out, will eventually affect your ability to work on shared repos. If you know what's happened before the force push, sometimes a force push is ok. If you don't, it's never ok.
    – Warren P
    Commented Dec 4, 2017 at 16:39
35

Some of you may be getting this error because Git doesn't know which branch you're trying to push.

If your error message also includes

error: failed to push some refs to '[email protected]:jkubicek/my_proj.git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. If you did not intend to push that branch, you may want to
hint: specify branches to push or set the 'push.default' configuration
hint: variable to 'current' or 'upstream' to push only the current branch.

then you may want to follow the handy tips from Jim Kubicek, Configure Git to Only Push Current Branch, to set the default branch to current.

git config --global push.default current
0
34
git pull origin branch_name --rebase

This worked for me -- the command git pull origin branch_name --rebase will pull changes from remote branch_name at first, then rebase current branch on the top of it.

0
20

In addition to the answers above, the following worked for me : -

Scenario -

  1. I pushed my_branch to origin successfully.
  2. I made few more changes.
  3. When I tried to push again, (after doing add, commit of course), I got the above mentioned error.

Solution -

 1. git checkout **my_branch**
 2. git add, commit your changes.
 3. git pull origin **my_branch** (not origin, master, or develop)
 4. git push origin **my_branch**

Proof

1
  • 1
    You have helped me. I had a hard time to notice that I needed to checkout to another branch and pull it from remote, even though I was pulling on another branch using the --all flag.
    – MZanetti
    Commented Oct 28, 2019 at 14:20
19

I had the same problem , what I did was I first pushed it by force by using this

git push --force

I did this after I commited the files and was getting an error as you got.It did commit all the files and it pushed them. Then the next time I was pushing to the github .I did what it asked me to and it was alright then. Hope this works for you too :)

5
  • It will work but it may not be what you want! It means you are basically just ignoring changes that will now be lost forever.
    – rollsch
    Commented Jun 7, 2018 at 1:17
  • 3
    git push --set-upstream origin master --force
    – Legends
    Commented Jun 30, 2018 at 14:34
  • 1
    Great way to destroy a repository. If you force push you will destroy history. Also many professionally setup git code bases won't allow you to do this. Commented Jul 20, 2018 at 9:43
  • This is a duplicate answer, and the original was not great advice anyway.
    – moopet
    Commented Aug 1, 2018 at 11:15
  • This is actually what I want to do but I just tried with Gitlab, and Gitlab doesn't allow this on "protected branches" by design Commented May 27, 2020 at 11:49
14

I mentioned this in my tutorial, How To Use GitHub: A tutorial for beginners.

When you create a new repository on GitHub, GitHub may ask you to create a readme file. If you create a readme file directly on GitHub, then you will need to first make a ‘pull’ request before the ‘push’ request will be successful. These commands will ‘pull’ the remote repository, merge it with your current files, and then ‘push’ all the files back to GitHub:

git pull https://github.com/thomas07vt/MyFirstRepo.git master

git push https://github.com/thomas07vt/MyFirstRepo.git master
2
  • I know this is a year later, but out of all these answers, yours was the only one that actually explained why I was already having trouble day 1 with github. What's the difference between pull and fetch though? Commented Jan 11, 2016 at 23:06
  • 1
    Fetch allows you to poke around in changes without merging them into your local branch. Pull is a shortcut to fetch and then merge. I'm sure you figured that out in the last 13 months. I'm just passing through because I've created a mess of my own. ;-) Commented Feb 16, 2017 at 15:59
7

git push -f origin branchname

Use the above command only if you are sure that you don't need remote branch code otherwise do merge first and then push the code

1
  • 6
    This is a duplicate of a bad answer.
    – moopet
    Commented Aug 1, 2018 at 11:16
7

Your branch should include the latest merged changes as soon as you notice them, but you haven't pulled the latest changes.

git fetch 

might be all that is needed. If that doesn't work, then you might need to:

git pull <sharedRepo> <branch> --rebase

If you don't have any merge conflicts, you should be able to push your changes successfully.

git push <forkedRepo> <branch>

If you encounter merge conflicts, you cannot solve them remotely in GitHub. You have to solve them locally and then push the resolutions with a force label because a merge conflict resolution changes history.

git push <forkedRepo> <branch> -f
0
6

I was getting the above mentioned error message when I tried to push my current branch foobar:

git checkout foobar
git push origin foo

It turns out I had two local branches tracking the same remote branch:

foo -> origin/foo (some old branch)
foobar -> origin/foo (my current working branch)

It worked for me to push my current branch by using:

git push origin foobar:foo

... and to cleanup with git branch -d

5

Just had the same issue but in my case I had typed the wrong branch on the remote. So, it seems that is another source of this issue... double check you're pushing to the correct branch.

1
  • 1
    And I had a similar thing, where I had recalled a previous command, which had was for a completely different repository! Commented Aug 19, 2013 at 20:45
5

I experienced the very same problem and it turned out I was on a different (local) branch than I thought I was AND the correct local branch was behind in commits from remote.

My solution: checkout the correct branch, cherry-pick the commit from the other local branch, git pull and git push

5

I had a similar issue and it turned out that my workflow for keeping my branch up to date was at fault. I was doing the following:

In my local 'master'

git fetch upstream
git merge upstream/master --ff-only

then back in my local branch

git rebase master

This worked well for a previous git flow but not with github. The git rebase was the problem here causing issues with syncing (and I'll admit that's something I've had to accept without fully understanding) and unfortunately put me in a position where git push -f became probably the easiest option. Not good.

My new flow is to update the branch directly using git merge as follows:

In my local branch

git fetch upstream
git merge upstream/master

No fast forward, as I will have made changes of course in the local branch.

As you can probably tell, I'm no git expert but I'm reliably informed that this workflow will probably avoid the specific problems that I had.

0
4

In my case, I had "mybranch" checked out, and had done git pull, so I couldn't figure out why the push wasn't working. Eventually, I realized that I was pushing the wrong branch. I was typing git push origin master instead of git push origin mybranch.

So if you've already done git pull and still getting this message, make sure you're pushing the correct branch.

4

Is your branch name the same as the remote branch name?

If no, you should checkout a new branch with the same name as the remote branch and try push it again.

Assume the remote branch you want to push is [testing] and your local branch is named as [test].

If you`re not in test branch, first switch to it.

git checkout test

Then open a new branch and name it testing.

git checkout -b testing

Now, it`s time to push it:

git push [remote repo] testing
1
  • 2
    Just use $git branch -M <new_name> to rename local branch.
    – coms
    Commented May 19, 2014 at 14:36
4

If you are certain that no one made changes to your git repository and that you are working on the latest version, git pull doesn't make sense as a solution in your heart...

Then this is probably what happened, you used git commit --amend

It lets you combine staged changes with the previous commit instead of committing it as an entirely new snapshot. It can also be used to simply edit the previous commit message without changing its snapshot.

ATLASSIAN tutorial: rewriting history

However, it is not recommended to perform git commit --amend if you have already pushed the commit to GitHub, this is because "amending doesn’t just alter the most recent commit—it replaces it entirely. To Git, it will look like a brand new commit" which means to other developer on your GitHub, history looks like A->B->C but to you it looks like A->B->D, if GitHub let you push, everyone else will have to manually fix their history

This is the reason why you get the error message ! [rejected] master -> master (non-fast-forward), if you know that no one has pulled your latest change, you can do git push --force, this will alter the git history in your public repo. Otherwise...you can perform git pull, but I believe this will have the same result as you didn't go through git commit --amend,it will create a new commit (ie: git history after git pull: A->B->C->D)

for more detail: How to change your latest commit

1
  • 1
    I had been wondering for a while what was causing that error every once in a while, and your answer makes a lot of sense. Plus it sorted out my problem in a fraction of the time of past events. Thanks! Commented Oct 5, 2020 at 22:31
4

I have resolve this issue at my GIT repository. No need to rebase or force commit in this case. Use below steps to resolve this -

local_barnch> git branch --set-upstream to=origin/<local_branch_name> 

local_barnch>git pull origin <local_branch_name>

local_barnch> git branch --set-upstream to=origin/master

local_barnch>git push origin <local_branch_name>

hope it will help.

3

Another solution is to advance the head of the remote by making another commit if you can. After you pull this advanced head into the local subtree then you will be able to push from it again.

3

I was getting a similar error while pushing the latest changes to a bare Git repository which I use for gitweb. In my case I didn't make any changes in the bare repository, so I simply deleted my bare repository and cloned again:

git clone --bare <source repo path> <target bare repo path>
3

Another option: locally rename your branch to something new.

You will then be able to push it to the remote repository, for example if that is your way of keeping a copy (backup) and making sure nothing gets lost.

You can fetch the remote branch to have a local copy and examine the differences between (i) what the remote had (with the old branch name) and (ii) what you have (with the new branch name), and decide what to do. Since you weren't aware of the remote's differences in the first place (hence the problem), simply merging or forcing changes somewhere is far too brutal.

Look at the differences, pick which branch you want to work on, cherry pick changes you want from the other branch, or revert changes you don't want on the branch you've got etc.

Then you should be in a position to decide whether you want to force your clean version onto the remote, or add new changes, or whatever.

2

The problem with push command is that you your local and remote repository doesn't match. IF you initialize readme by default when creating new repository from git hub, then, master branch is automatically created. However, when you try to push that has no any branch. you cannot push... So, the best practice is to create repo without default readme initialization.

2

This problem is usually caused by creating a readme.md file, which is counted as a commit, is not synchronized locally on the system, and is lacking behind the head, hence, it shows a git pull request. You can try avoiding the readme file and then try to commit. It worked in my case.

0

Another cause of this problem (apparently not so common)...

My server was behind ~12 hours when I did a push

I configured NTP on the server SYNC my clock.

I executed a new git push which led the error discussed in this post.

0

If by any chance git pull prints Already up-to-date then you might want to check the global git push.default param (In ~/.gitconfig). Set it to simple if it was in matching. The below answer explains why:

Git - What is the difference between push.default "matching" and "simple"

Also, it is worth checking if your local branch is out of date using git remote show origin and do a pull if needed

0

use git pull https://github.com/username/repository It's because the Github and remote repositories aren't in sync. If you pull the repo and then Push everything will be in sync and error will go away.

`

0

You won't be able to push changes to remote branch unless you unstage your staged files and then save local changes and apply the pull from remote and then you can push your changes to remote.

The steps are as follows-->

git reset --soft HEAD~1 ( to get the staged files)

git status (check the files which are staged)

git restore --staged <files..> (to restore the staged)

git stash (to save the current changes)

git pull (get changes from remote)

git stash apply (to apply the local changes in order to add and commit)

git add <files…> (add the local files for commit)

git commit -m ‘commit msg’

git push

Not the answer you're looking for? Browse other questions tagged or ask your own question.