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?
git pull origin FixForBug
before I push to that? Ok that makes sense. Feel free to add as an answer!
develop
branch before pushing to it the first time and got past this error.
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.
*"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.
git push -f
but it says Everything is up to date. any other idea?
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
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
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
.
-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 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.
We can force changes to GitHub using our local repository with the following cmd:
git push -f origin main
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:
https://i.stack.imgur.com/TnV5B.png
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
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
Next
You'll need to stash your commit.
Here's how:
git reset --soft HEAD~1
git stash
Now rebase with your upstream branch:
git fetch upstream beta && git rebase upstream/beta
Now pop your stashed commit:
git stash pop
Commit these changes and push them:
git add -A
git commit -m "[foo] - foobar commit"
git push origin fix/#123 -f
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
Me help next:
git stash
git pull origin master
git apply
git commit -m "some comment"
git push
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
If you use TortoiseGit push dialogue
https://i.stack.imgur.com/MwE9k.png
Cite source: https://tortoisegit.org/docs/tortoisegit/tgit-dug-push.html#id692368
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.
If you are really worried about any other approaches, these Steps can help you without any difficutly
1: Stash your changes in your Local Branch that you want to Push
2: Rename Your Local Branch as your Backup for future
3: Create a Branch of the Same name From your Remote that will have all the changes
4: Check out this new Branch as your New Local Branch
5: Make and Save the Changes in this Branch
6: Commit and Push
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
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...
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.
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.
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.
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.
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).
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
I dont know why git dont make this clear on their website
Start by clearing any git commits without changing your code:
git reset --soft HEAD~1
git reset --soft HEAD~2
etc
If git pull didnt solve problem, create a branch and switch to it. This will be your first push and you need to use a SEPARATE branch...
git checkout -b tempbranch
"checkout" will create the tempbranch. use "git status" to see if you're in tempbranch
Ensure youre going to push to the right place ...
git remote add origin https://github.com/user/examplerepo.git
git remote set-url origin https://github.com/user/examplerepo.git
Work on tempranch and then add new files or folders and Though youre on a separate branch the folder structure is same as master default branch. So add ....
git add file.txt
after adding the file is now in stating area. Here you can use git status to see what is ready to be committed. then you can commit:
git commit -m "Put some print statements" file.txt
Now the file in is local repo and you will not see it using "git status". but you can see the list of committed files using "git log" and "git ls-files"
Since this is the first time you push to origin....
git push -u origin tempbranch
Next time you can just work on master branch so u can switch to it
git checkout master
Also you can check this link for more info https://practicalgit.com/blog/do-you-always-need-u-in-push.html
Success story sharing
git push -f
but it says Everything is up to date. any other idea?Sorry, force-pushing to main is not allowed