28

I just finished working on a piece of code and when I went to push the changes, I got the already famous:

hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g. 
hint: 'git pull ...') before pushing again.

I've seen this question posted several times here, e.g. (1) and (2).

Accordingly, the solution is to either:

  • git pull, so that the remote changes are merged on to my local work, or
  • git push -f, a force push to update the remote (origin) branch.

Now, it has been a while since I've worked on this branch. I don't necessarily want to merge the remote changes onto my current work! Nor do I know if I can safely force the update on the origin branch...

How can I just see the differences and decide which is best for my case?

Kyle F Hartzenberg
  • 2,567
  • 3
  • 6
  • 24
transient_loop
  • 5,984
  • 15
  • 58
  • 117
  • There is probably no avoiding friction if you want to bring your changes into the remote branch. The best course of action is to keep your local branch updated with the remote changes. For now, you could try just merging as a dry run to see how bad the conflicts might be. – Tim Biegeleisen Jul 25 '17 at 03:16
  • 3
    `git push -f` discards all progress done to the remote repository by other people, unless it is your personal repository you probably do not want it. – max630 Jul 25 '17 at 04:47
  • https://stackoverflow.com/a/21088381/12201407 – jeevu94 Dec 15 '20 at 10:59

5 Answers5

15

in order to see the differences, first you need to fetch the commits from the origin repository:

git fetch origin

Now you can see the diffs (Assuming you are on the master branch) git diff HEAD..origin/master

Now you are armed with the knowledge you seek to decide to merge or rebase before pushing your changes.

Ben
  • 1,287
  • 15
  • 24
  • 4
    Two points mixes together differences done to remote and local branches. In this case it would be better to use [three-dots diff](https://git-scm.com/docs/git-diff#git-diff-emgitdiffem--optionsltcommitgtltcommitgt--ltpathgt82308203) to see changes specific to either local or remote side. – max630 Jul 25 '17 at 04:54
  • Very strange. I did the same and there is no difference – KansaiRobot May 26 '20 at 02:57
  • If there are no differences, you have the option to move your branch pointer to origin/master with a flavor of `git reset` – Ben May 29 '20 at 20:18
  • `git diff HEAD..origin/master` => `fatal: ambiguous argument 'HEAD..origin/master': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]'` – Petrus Theron Aug 11 '23 at 09:16
13

I had this happen to me recently when I created a new branch with git checkout -b feature/abc, committed some changes, and then tried git push --set-upstream origin feature/abc it to create a pull request for review. The error occurred because the remote branch already existed when I thought I was defining the branch locally. Deleting the remote branch resolved the issue and my push succeeded.

djb
  • 4,930
  • 1
  • 34
  • 37
  • How do you delete the remote branch? – Bluz Jan 18 '19 at 11:54
  • We were using BitBucket, so the BitBucket UI shows the remote branch and I just deleted from there. The git CLI should also provide a way to delete remote branches... I just don't do it that way. – djb Jan 22 '19 at 15:00
  • Who knows why git was telling me I cannot do `git push` and suggesting I do `git push --set-upstream origin mybranch`, when you were right, there was a branch on github already. Thank you, it fixed it! @Bluz I just went to github and clicked on "Branches" and clicked the trash icon next to the same branch. – Rock Lee Jan 22 '19 at 21:20
  • 1
    This was the problem in my case as well. This answer deserves more upvotes. – philosopher Feb 07 '20 at 06:15
9

I found this command works correctly:

git push -u origin main -f

You just need to add a -f flag to force the push.

Alex Aaqil
  • 99
  • 1
  • 3
1

I wanted to add a scenario that happened to me recently where this error shows up seemingly out of nowhere, even when you do everything right. The cause wasn't obvious but finally seemed to be the change in default push behavior since git version 2.0. I was collaborating with someone using git version 1.8 and I had version 2.x. So although we were both doing git push, different types of push were happening. For us, the problem resolved once we changed the default push behavior by simply running this command on git version 1.8 computer-

git config --global push.default simple

This changes the push.default of git version >=1.7 to same as for version 2.0 onwards. For lower versions of git, you might need another default behavior. We both are new to git so correct me if I am wrong but this did made our "Updates were rejected..." error go away.

Also, if there is a better venue for this answer, let me know and I'll be happy to move it to somewhere else.

tu_curious
  • 387
  • 4
  • 13
0

If you mean to discard your local changes you should run git reset --hard @{u}. Note again this is irreversible action wrt some data, so be sure before running it. Here's how:

To review which local commits you currently have you can use git log HEAD --not --remotes, to compare to any remote branch or git log @{u}..HEAD to see differences specific to the tracked branch.

To see the actual diff which you have committed locally, run git diff @{u}.... This will ignore remote progress, and show only your changes.

To see uncommitted changes, run git diff HEAD.

PS: You should run first git fetch origin or git remote update to update the tracking references.

max630
  • 8,762
  • 3
  • 30
  • 55