779

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

Pushing to git@github.com:519ebayproject/519ebayproject.git
To git@github.com:519ebayproject/519ebayproject.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com: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?

starball
  • 20,030
  • 7
  • 43
  • 238
user1353717
  • 7,823
  • 3
  • 14
  • 3
  • 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? – Thorbjørn Ravn Andersen Feb 19 '13 at 09:27
  • 52
    @ThorbjørnRavnAndersen - I managed to fix this scenario using 'git push -f' which seemed to make git forget about its imaginary problems :) – Echelon May 28 '13 at 14:37
  • you can refer http://stackoverflow.com/questions/12650261/git-says-local-branch-is-behind-remote-branch-but-its-not – Sumit Kapadia Jun 24 '13 at 15:27
  • @Echelon I wonder why it dreams so much. This has happened to me a couple of times. (and each time I forget how to fix it :P) – viki.omega9 Jul 18 '13 at 17:49
  • 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. – Ruslan Kabalin Oct 14 '13 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 Jan 14 '14 at 10:47
  • @RuslanKabalin - but GitHub itself recommends to add ReadMe and if someone unchecks it, it prompts you to add it manually :) – rh979 Jan 13 '15 at 09:42
  • 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. – developer747 Mar 05 '15 at 16:26
  • This error also comes post squash and trying to push to remote – vikramvi Jul 14 '16 at 13:05
  • I got the same problem, and not solved by the simple git pull -- all. It is indeed a new repo, clean, but with license added, a service added to show progress on README.md. Before these addition it worked nicely from the cmd line. Which one is the tip? – mariotti Jan 20 '17 at 21:04
  • In my case I forgot to use the branch name : git push -u origin branch_name – Dan M. CISSOKHO Oct 16 '17 at 08:44

31 Answers31

782

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.

Nick Volynkin
  • 14,023
  • 6
  • 43
  • 67
Nick Rolando
  • 25,879
  • 13
  • 79
  • 119
  • 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 Nov 14 '13 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. – Adam Kalnas Apr 29 '14 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... – rickfoosusa Aug 09 '16 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](https://help.github.com/articles/about-pull-requests/): "Force pushing can corrupt your pull request". – Armfoot Jul 17 '17 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 Aug 23 '19 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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Jake Greene
  • 5,539
  • 2
  • 22
  • 26
  • 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? ~~~ – Steve Pitchers Nov 26 '12 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]) – Jake Greene Nov 27 '12 at 18:40
  • 1
    Great explanation. This [video](https://www.youtube.com/watch?v=h1e8oC7g0Ps&index=11&list=PL5-da3qGB5IBLMp7LtN8Nc3Efd4hJq0kD) 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. – Kevin Markham Oct 26 '14 at 17:45
  • 4
    *some* years later, it just seems that this answer is very very similar to [this other](http://stackoverflow.com/a/12651066/540776) – superjos Aug 12 '15 at 13:03
  • I posted this answer in April of 2012 and it seems someone copied it in September of 2012. Thanks for letting me know – Jake Greene Aug 12 '15 at 22:25
  • Or git pull says E325: ATTENTION .. before it shoves me into a vim shell. – Jan Jansz Jun 26 '17 at 18:54
  • 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 Oct 06 '18 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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
AYK
  • 3,312
  • 1
  • 17
  • 30
  • 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 Dec 17 '12 at 05: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 "git@github.com" paths or HTTPS paths, from which you should be able to identify where to push. Hope this helps ! – AYK Dec 17 '12 at 05:38
  • Nothing happen when I typed `git remote --verbose`. But after I add the `origin`, everything goes fine. Thank you. – Ziyuan Dec 17 '12 at 06:15
  • 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 Apr 20 '16 at 13:04
  • 2
    @Shubh did you ever solve the issue? Im getting the same thing! – OriginalAlchemist May 03 '16 at 07: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 ` e.g. **git push origin ** check this [thread](http://stackoverflow.com/a/10510482/2624806). – CoDe May 03 '16 at 10:03
  • @AYK Question: Do I need to re-build the entire maven project before pushing my changes to origin? – user2441441 Aug 10 '16 at 23:24
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).

prayagupa
  • 30,204
  • 14
  • 155
  • 192
  • 4
    where is the `commit`? Should you not commit your changes after `stash pop`? – mehmet May 18 '16 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. – prayagupa Oct 18 '17 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

Smit Patel
  • 1,682
  • 18
  • 23
  • 6
    Deleting your git repo and losing your entire commit history is a "Recommended" solution? Seems hasty. – Nils Guillermin Feb 04 '19 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. – Smit Patel Apr 27 '19 at 02: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. – InfiniteZoom Aug 16 '20 at 02: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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Teo
  • 535
  • 4
  • 3
  • $git push --force origin master – Shaurya Uppal Oct 03 '17 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. – mike rodent Nov 19 '17 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 Dec 04 '17 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 'git@github.com: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
kubi
  • 48,104
  • 19
  • 94
  • 118
xiatica
  • 1,546
  • 2
  • 20
  • 24
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.

cmaher
  • 5,100
  • 1
  • 22
  • 34
Pyuri Sahu
  • 449
  • 4
  • 4
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

Bhavuk Mathur
  • 1,048
  • 1
  • 12
  • 22
  • 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 Oct 28 '19 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 :)

Matthieu Moy
  • 15,151
  • 5
  • 38
  • 65
Kailash Bhalaki
  • 282
  • 3
  • 5
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
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Thomas07vt
  • 219
  • 1
  • 4
  • 11
  • 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? – Xander Luciano Jan 11 '16 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. ;-) – wolfhoundjesse Feb 16 '17 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

VIKAS KOHLI
  • 8,164
  • 4
  • 50
  • 61
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
ScottyBlades
  • 12,189
  • 5
  • 77
  • 85
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

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Marco
  • 139
  • 3
  • 5
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.

longda
  • 10,153
  • 7
  • 46
  • 66
  • 1
    And I had a similar thing, where I had recalled a previous command, which had was for a completely different repository! – Clare Macrae Aug 19 '13 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

Ramon Fincken
  • 253
  • 1
  • 5
  • 11
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.

Component 10
  • 10,247
  • 7
  • 47
  • 64
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
Community
  • 1
  • 1
fox323
  • 41
  • 1
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.

wisbucky
  • 33,218
  • 10
  • 150
  • 101
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

watashiSHUN
  • 9,684
  • 4
  • 36
  • 44
  • 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! – Giampaolo Ferradini Oct 05 '20 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.

Sai prateek
  • 11,842
  • 9
  • 51
  • 66
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>
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Hemant
  • 4,537
  • 8
  • 41
  • 43
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.

9swampy
  • 1,441
  • 14
  • 24
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.

Ivan
  • 4,383
  • 36
  • 27
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.

Suman Astani
  • 1,181
  • 11
  • 16
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.

Auden Young
  • 1,147
  • 2
  • 18
  • 39
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.

XMAN
  • 176
  • 1
  • 3
  • 12
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.

`

Mahi
  • 1,164
  • 17
  • 24
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

abhinav kumar
  • 1,487
  • 1
  • 12
  • 20
0

If you work solo and you recently used ammend to change some commit that you have pushed, use this: (change branch if it's not origin master)

git push -f origin master
jsHate
  • 499
  • 1
  • 3
  • 20