Updates were rejected because the tip of your current branch is behind its remote counterpart

Question

Our workflow is such. We have a branch called dev which I can reach at origin/dev. When we do changes, we create a branch off dev:

git checkout -b FixForBug origin/dev

Now I have a branch called FixForBug which is tracking (I think that's the right word) origin/dev. Thus, if I do a git pull it'll bring in new changes from origin/dev which is great. Now, when I'm finished with my fix, I push to a remote branch called the same thing.

First I pull down any changes from origin/dev and do a rebase:

git pull --rebase

Then I push the changes to a remote branch of the same name:

git push origin FixForBug

Now, there's a branch on the remote server and I can create a pull request for that change to be approved and merged back in to the dev branch. I don't ever push anything to origin/dev myself. I'm guessing this is as pretty common workflow.

The first time I do a git push, it works fine and creates the remote branch. However, if I push a second time (let's say during code-review, someone points out a problem), I get the following error:

error: failed to push some refs to 'https://github.mydomain.info/Product/product.git'
hint: Updates were rejected because the tip of your current branch is behind its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again.
See the 'Note about fast-forwards' in 'git push --help' for details.

However, if I do a git status it says I'm ahead of origin/dev by 1 commit (which makes sense) and if I follow the hint and run git pull, it says everything is up to date. I think this is because I'm pushing to a different branch than my upstream branch. I can fix this issue by running:

git push -f origin FixForBug

In that case, it'll push the changes to the remote branch, saying (forced update) and everything appears to be good on the remote branch.

My Questions:

Why is -f required in this scenario? Usually when you're forcing something, it's because you were doing something wrong or at least against standard practice. Am I ok doing this, or will it mess up something in the remote branch or create a hassle for whoever has to eventually merge my stuff into dev?

It seems like the message you are getting is saying that the remote branch FixForBug is ahead of your local branch FixForBug. You should pull down the changes from that remote branch and merge them into your local branch before pushing. — mhatch, Sep 08 '16 at 20:52
@mhatch - So basically run `git pull origin FixForBug` before I push to that? Ok that makes sense. Feel free to add as an answer! — Mike Christensen, Sep 08 '16 at 21:08
for pushing herku if you get this error do this. https://stackoverflow.com/a/21088381/12201407 — jeevu94, Dec 15 '20 at 11:00
[Stack Overflow's most copied question with plain text](https://stackoverflow.blog/2021/04/19/how-often-do-people-actually-copy-and-paste-from-stack-overflow-now-we-know/)... — Peter Mortensen, Apr 21 '21 at 16:55
If you just cloned this repo try pulling the remote origin. I cloned our repo and forgot to pull the `develop` branch before pushing to it the first time and got past this error. — Paul G, Mar 30 '22 at 16:53
In my case I merged a base branch into current (because base branch got many new commits). Then pushed current branch and got this error message. I reviewed branches again and found that another branch merged to current (don't know how). So, I reset current branch and merged with base branch again. Then reviewed branches and pushed without error. — CoolMind, Jun 01 '22 at 22:03
Not sure but sometimes this error happens when you have a branch in remote with the same name as you're pushing (and maybe PR as created from that branch). You need to delete the branch and close the PR. — Neeraj Sonaniya, Sep 27 '22 at 07:00
@NeerajSonaniya, agree. We can close MR/PR and rename current branch or delete remote. — CoolMind, Feb 17 '23 at 08:42
I had this question so many times! I wonder here who updated the remote branch, since it's probably YOUR branch and nobody made changes to it... — Paul Pacurar, Mar 14 '23 at 10:41

score 864 · Accepted Answer · edited Feb 07 '20 at 07:42

864

The -f is actually required because of the rebase. Whenever you do a rebase you would need to do a force push because the remote branch cannot be fast-forwarded to your commit. You'd always want to make sure that you do a pull before pushing, but if you don't like to force push to master or dev for that matter, you can create a new branch to push to and then merge or make a PR.

edited Feb 07 '20 at 07:42

Pingolin

3,161
6
25
40

answered Sep 08 '16 at 21:47

Keif Kraken

9,500
1
10
12

13

Could you clarify the point "You'd always want to make sure that you do a pull before pushing"? It is clear why "push -f" after rebase of the local branch is required. In this case, won't the rebase of the local be undone by doing a pull w.r.t. the remote before pushing? – Hari Apr 17 '20 at 07:57
3

I was thinking about the same, If I pull the files that I rebased then I would be doing a rebase for nothing. Still thanks for the force push, was having issues figuring this out. – claudiodfc Dec 12 '20 at 21:41
1

Thanks. I like that you explained why we have to -f (force). It makes sense now. – No One Jan 30 '21 at 00:44
2

I tried `git push -f` but it says Everything is up to date. any other idea? – arielma Nov 14 '21 at 07:04
I get ```Sorry, force-pushing to main is not allowed``` – Shubham Saroj Mar 17 '22 at 20:32
when you `git pull origin/dev` (to bring remote changes in dev or master to local dev or master) and then you do `git checkout FixForBug` && `git rebase dev`, that means whatever changes you had in your local `FixForBug` branch will be put on top of `local dev` branch , Now when you want do `git push origin FixforBug` fast forwarding on remote cannot be done (because your local changes might have be diverged easily), in that case `git push -f orgin FixForBug` is necessary – yogender Feb 10 '23 at 12:44
This solved my problem(s). Thank you! – oaklandrichie Aug 30 '23 at 20:50

Talha Rafique · Answer 2 · 2021-09-09T14:33:57.563

501

*"The tip of your current branch is behind its remote counterpart"* means that there have been changes on the remote branch that you don’t have locally. And Git tells you to import new changes from REMOTE and merge it with your code and then push it to remote.

You can use this command to force changes to the server with the local repository (). remote repo code will be replaced with your local repo code.

git push -f origin master

With the -f tag you will override the remote branch code with your local repo code.

edited Sep 09 '21 at 14:33

answered Jun 26 '20 at 22:11

Talha Rafique

5,282
1
10
11

1

Better to enable force push incase your branch is protected – Waleed93 Apr 28 '21 at 10:52
2

this has actually worked for me after a few minutes of frustration – NMukama Nov 02 '21 at 20:51
2

I tried `git push -f` but it says Everything is up to date. any other idea? – arielma Nov 14 '21 at 07:02
i used 'git push -f origin main' and it worked – Njuguna_nc Nov 17 '21 at 13:43
4

Wouldn't this command simply push all local changes to master and wipe the remote changes? – Yashank Nov 30 '21 at 17:15
2

This doesnt address the OP's situation and/or question; the OP had no changes on the remote branch that the local one did not have. – Olivier Jan 17 '22 at 08:43
yes @Olivier you are right. well, i have tried many things to know what is the reason behind if says code is different on local and remote. but nothing was found, so this command works as we want to do the work. – Talha Rafique Jan 20 '22 at 11:37
who in the world pushed changes, since that's usually the personal branch under a PR and no one else pushes to it? – Paul Pacurar Mar 14 '23 at 10:45
@Yashank, you are right! I have used because all I need now is to have the remote repo have everything in my local repo and not the otehr round. – Gathide Jun 06 '23 at 11:21

score 122 · Answer 3 · answered Sep 09 '16 at 14:45

122

To make sure your local branch FixForBug is not ahead of the remote branch FixForBug pull and merge the changes before pushing.

git pull origin FixForBug
git push origin FixForBug

answered Sep 09 '16 at 14:45

mhatch

4,441
6
36
62

30

OP stated they already did a git pull and tried pushing. Your answer doesn't apply to OP's question. – Patrick Dec 02 '19 at 02:38
2

it does apply. git pull and git pull origin it's different things. – Vasyl Gutnyk Nov 22 '22 at 13:27
this helped me, as when you have multiple branches locally unless you do git pull origin it will not work. – Jai Prakash Jan 20 '23 at 05:38

score 47 · Answer 4 · edited Jun 05 '21 at 21:35

47

Set the current branch name, like master:

git pull --rebase origin master git push origin master

Or branch name develop

git pull --rebase origin develop git push origin develop

edited Jun 05 '21 at 21:35

Peter Mortensen

30,738
21
105
131

answered Sep 15 '20 at 18:07

Golam Sorwar

1,255
15
12

score 41 · Answer 5 · answered Sep 08 '16 at 22:07

41

If you want to avoid having to use -f, then you can use just

git pull

instead of

git pull --rebase

The non-rebase will fetch the changes from origin/dev and merge them into your FixForBug branch. Then, you will be able to run

git push origin FixForBug

without using -f.

answered Sep 08 '16 at 22:07

Greg Hewgill

951,095
183
1,149
1,285

6

Rebase is part of our work flow here. I'll get yelled at if I don't do it. – Mike Christensen Sep 09 '16 at 06:03
2

@MikeChristensen: Okay, well then follow the documented procedure of course. From what you describe, you will need to use `-f` because you are *replacing* commit(s) on the upstream repository with different ones that have a different (rebased) history. If you were to use a product such as [Gerrit](https://www.gerritcodereview.com) then it supports this sort of rebasing code-review workflow without having to use `-f` when pushing. We use Gerrit at work in this way and it works very well. – Greg Hewgill Sep 09 '16 at 06:35

score 31 · Answer 6 · edited Jun 05 '21 at 21:47

31

We can force changes to GitHub using our local repository with the following cmd:

git push -f origin main

edited Jun 05 '21 at 21:47

Peter Mortensen

30,738
21
105
131

answered May 09 '21 at 15:25

Sachin Mewar

503
5
6

I was working in my local setup, I have just need to force push my changes to main branch repo, it works fine for me – Janardhan Reddy May 18 '21 at 17:35

score 12 · Answer 7 · edited Jun 05 '21 at 21:14

The command I used with Azure DevOps when I encountered the message "updates were rejected because the tip of your current branch is behind" was/is this command:

git pull origin master

(or can start with a new folder and do a clone)...

This answer doesn't address the question posed, specifically, Keif has answered this, but it does answer the question's title/heading text and this will be a common question for Azure DevOps users.

I noted comment: "You'd always want to make sure that you do a pull before pushing" in the answer from Keif!

I have also used Git GUI tool in addition to the Git command line tool.

(I wasn't sure how to do the equivalent of the command line command "git pull origin master" within Git GUI, so I'm back to the command line to do this).

A diagram that shows the various Git commands for various actions that you might want to undertake is this one:

score 11 · Answer 8 · edited Jun 05 '21 at 21:16

11

It must be because of the commit is ahead of your current push.

git pull origin "name of branch you want to push"
git rebase

If git rebase is successful, then good. Otherwise, you have resolve all merge conflicts locally and keep it continuing until the rebase with remote is successful.
git rebase --continue

edited Jun 05 '21 at 21:16

Peter Mortensen

30,738
21
105
131

answered Sep 14 '19 at 11:10

kris

979
11
15

score 7 · Answer 9 · edited Jun 05 '21 at 21:22

7

This just happened to me.

I made a pull request to our master yesterday.
My colleague was reviewing it today and saw that it was out of sync with our master branch, so with the intention of helping me, he merged master to my branch.
I didn't know he did that.
Then I merged master locally, tried to push it, but it failed. Why? Because my colleague merge with master created an extra commit I did not have locally!

Solution: Pull down my own branch so I get that extra commit. Then push it back to my remote branch.

On my branch I literally did:

git pull
git push

edited Jun 05 '21 at 21:22

Peter Mortensen

30,738
21
105
131

answered Jan 17 '20 at 15:02

mfaani

33,269
19
164
293

1

That's true. But I think the situation described in the problem is that there were actually no new changes on the remote as compared to the local branch. – havryliuk Sep 29 '22 at 07:22

score 7 · Answer 10 · edited Jun 05 '21 at 21:49

7

In my case, the remote repository already had a branch with the same name as the dev branch that I was working on. I just renamed the branch and pushed the code. It worked for me.

git checkout -b new-branch-name
git push origin new-branch-name

edited Jun 05 '21 at 21:49

Peter Mortensen

30,738
21
105
131

answered May 25 '21 at 03:36

Davis Benny

99
1
3

1

This applies to me! – Vkl125 Jan 24 '22 at 16:30
Yes, this is the workaround I have been using for years. But I suppose what we need is an automated fix. – havryliuk Sep 29 '22 at 07:20

score 5 · Answer 11 · edited Jun 05 '21 at 21:21

This is how I solved my problem:

Let's assume the upstream branch is the one that you forked from and origin is your repository and you want to send an MR/PR to the upstream branch.

You already have, let's say, about four commits and you are getting Updates were rejected because the tip of your current branch is behind.

Here is what I did

First, squash all your four commits:

git rebase -i HEAD~4

You'll get a list of commits with pick written on them (opened in an editor).

Example

pick fda59df commit 1
pick x536897 commit 2
pick c01a668 commit 3
pick c011a77 commit 4

to

pick fda59df commit 1
squash x536897 commit 2
squash c01a668 commit 3
squash c011a77 commit 4

After that, you can save your combined commit

known changes - This allows remote repository to accept a safer non-fast-forward push. This can cause the remote repository to lose commits; use it with care. This can prevent from losing unknown changes from other people on the remote. It checks if the server branch points to the same commit as the remote-tracking branch (known changes). If yes, a force push will be performed. Otherwise it will be rejected. Since git does not have remote-tracking tags, tags cannot be overwritten using this option. This passes --force-with-lease option of git push command.

unknown changes - This allows remote repository to accept an unsafe non-fast-forward push. This can cause the remote repository to lose commits; use it with care. This does not check any server commits, so it is possible to lose unknown changes on the remote. Use this option with Include Tags to overwrite tags. This passes the traditional --force option of git push command.

score 2 · Answer 16 · answered Jan 31 '23 at 05:25

Over here when you are trying to rebase a dev-feature branch from the master branch (Git version for reference >> git version git version 2.37.1 (Apple Git-137.1) )

1.git checkout dev-feature

checkout the feature branch

2. git pull

update the head to the latest commit

3. git pull --rebase origin master

set up the rebase flag to pull from the master repo

4. git config pull.rebase true in case the reconcile method is not set , since you have 2 divergent branches 5. git pull Successfully rebased and updated refs/heads/dev-feature** if you get the above message it means the branch has been rebased

6. git push origin dev-feature Push these changes to remote

score 1 · Answer 17 · edited Jun 05 '21 at 21:25

1

I had this issue when trying to push after a rebase through Visual Studio Code. My issue was solved by just copying the command from the Git output window and executing it from the terminal window in Visual Studio Code.

In my case the command was something like:

git push origin NameOfMyBranch:NameOfMyBranch

edited Jun 05 '21 at 21:25

Peter Mortensen

30,738
21
105
131

answered May 07 '20 at 06:53

HoloLady

1,041
1
12
28

score 1 · Answer 18 · edited Jun 05 '21 at 21:43

1

The push were rejected because the tip of your current branch is behind.

When I had such a situation, I just ran:

git push -f origin main

And it was done.

edited Jun 05 '21 at 21:43

Peter Mortensen

30,738
21
105
131

answered Apr 14 '21 at 12:15

SHADRACH CHIGOZIE MADUAKO

29
1

2

`git push -f` will overwrite the upstream changes, and is technically correct. Most of the time, you want to add your changes to the existing code, so what you need to do is `git fetch` to get those changes, and then `git rebase origin/branchname` to replay your changes on top of upstream. There may be merge conflicts to address, but that way you aren't overwriting someone else's work. – Joe Block Apr 14 '21 at 13:15

score 1 · Answer 19 · edited Jun 05 '21 at 21:46

1

It depends on the permissions.

You may not have permission to push directly to a main branch (master, development). If you are in an enterprise project, you should push your own topic branch to its remote and submit a merge request (MR).

edited Jun 05 '21 at 21:46

Peter Mortensen

30,738
21
105
131

answered Apr 29 '21 at 13:37

gleitonfranco

791
6
9

score 0 · Answer 20 · edited Jun 05 '21 at 21:33

0

You must have added new files in your commits which has not been pushed. Check the file, push that file again, and then try pull / push.

It will work. This worked for me...

edited Jun 05 '21 at 21:33

Peter Mortensen

30,738
21
105
131

answered Aug 03 '20 at 07:06

Rahul Parab

27
7

score 0 · Answer 21 · edited Jun 05 '21 at 21:36

0

If you tried all of the previous answers and the problem is still not solved, then make sure that the pushed branch name is unique and does not exist in remotes.

The error message might be misleading.

edited Jun 05 '21 at 21:36

Peter Mortensen

30,738
21
105
131

answered Nov 13 '20 at 14:52

M.Erkan Çam

173
1
7

There is no related answer with my post. If there was then I would agree with you. – M.Erkan Çam Nov 14 '20 at 17:13

score 0 · Answer 22 · edited Jun 05 '21 at 21:45

0

Since the branch I was trying to commit was my sub branch under master, I deleted it first from the repository (due to a back referencing issue). I then retried with push and it worked again!

Note: As part of deleting the initial branch, I had all the previous changes in the push I was about to do so no code were lost.

edited Jun 05 '21 at 21:45

Peter Mortensen

30,738
21
105
131

answered Apr 15 '21 at 16:43

techloris_109

547
5
13

score 0 · Answer 23 · answered Sep 13 '22 at 15:52

0

Check your remote branch isn't locked.

answered Sep 13 '22 at 15:52

MagicLuckyCat

324
2
5
19

score 0 · Answer 24 · answered Sep 29 '22 at 07:27

I have encountered this problem in an automated environment only, namely Gitlab pipelines and Github actions, when during releases branches are merged and pushed automatically. The only manual solution that has worked for me is creating a new branch with the same changes and running the pipeline on the new branch.

I haven't yet figured out how to permenently fix it in Gitlab and Github pipelines.

Jiao · Answer 25 · 2022-11-11T22:41:31.303

0

your local master branch: -> HEAD~N -> updated & new files(can't push to github!)

your github master branch: -> HEAD~N -> AheadNewCommit1 -> AheadNewCommit2 ...

step1. reset to the HEAD~N

$  git reset --soft HEAD~N

step2: pull AheadNewCommit1 -> AheadNewCommit2 ... to your local master branch

$  git pull origin master

edited Nov 11 '22 at 22:41

answered Nov 11 '22 at 22:35

Jiao

111
1
3

score 0 · Answer 26 · answered Jun 21 '23 at 14:34

0

Not sure what the issue was for me, but I was receiving the same error message when trying to push.

What worked for me was

git push pmagunia HEAD:develop

You can replace pmagunia with the name of your remote or possibly origin.

answered Jun 21 '23 at 14:34

pmagunia

1,718
1
22
33

score -1 · Answer 27 · answered Jul 22 '23 at 10:45

-1

in android studio on the right bottom checkout to master/origin branch

answered Jul 22 '23 at 10:45

Azade Rahmati

135
1
5

score -4 · Answer 28 · answered Jul 18 '22 at 17:48

First, you have to fetch the changes from the remote, only then you will be able to push the changes, In order to do that you have to write the command

git pull

after that, you will find some conflict, resolve your conflict and then write the command

git push

This fix is working for me, give it a try and I think due to the conflict on the remote we are not able to push the code

Updates were rejected because the tip of your current branch is behind its remote counterpart

28 Answers28

Example

Next

Linked

Related