I am working on the team project on GitHub. I am facing the error :

Updates were rejected because a pushed branch tip is behind its remote counterpart. Check out this branch and integrate the remote changes (e.g. 'git pull ...') before pushing again.

Here is the situation : I pulled the main branch code from GitHub and started working on it locally and later I pushed the changes to temp_branch using this command.

git push origin main:temp_branch

Meanwhile, some other changes has been added to the main branch on GitHub (my changes on temp_branch are not yet merged) and I was told to make some additional changes.

Now, I have made the changes and trying to push to the same temp_branch using these two commands

git pull --rebase origin main
git push origin main:temp_branch

On doing this, I am getting the mentioned error. I was referring to this link but it does not exactly answers my problem and it suggests to use -f force push to override the content which I don't want to.

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

I want to know what exactly is happening here and how do I resolve this?

CodePudding user response：

First, I think you'll find it easier to checkout the branch you are working on and pushing out to your branch using the normal syntax:

git fetch # update your copy of the remote branches
git switch temp_branch # checkout temp_branch
git rebase origin/main
git status # make sure your branch is tracking origin/temp_branch and not main

You have asked 2 different questions here:

I want to know what exactly is happening here and how do I resolve this?

You already know "how to solve it", since the question you linked to answers that:

The -f is actually required because of the rebase.

You said you don't want to use -f, but you don't have a choice if you're using rebase. Maybe if we answer your first question you'll be more confident doing the force push.

"What exactly is happening?"

You'll need to understand how rebasing works first, and then you'll realize that anytime you rewrite a commit, the commit ID changes. Once you change a commit ID you essentially deleted the commits you had before and replaced them with new ones. Since the old ones are still on the remote branch, Git won't allow you to blow them away and replace them with your new ones unless you "force" push. Note there are different variants of force pushing. Please feel free to read up on the differences, but until then, I suggest always using git push --force-with-lease instead of the more common --force or -f. It's a little safer, and if that one fails, do another git fetch first, look at the new commits on the remote that you didn't know about to make sure you're still OK with blowing them away, and then do the --force-with-lease again.

It's perfectly fine to rebase your own branch and then force push it out, if no one else is sharing that branch with you. If it's a public repo then you should consider not pushing it out until you think you're done with it, if you intend to rebase. Otherwise you'll have to notify others that you're rewriting a branch that they may be working on. Note you almost never want to force push shared branches such as main though.

CodePudding user response：

if you have changes stash them by git add -u && git stash

check out the main branch git checkout main

then get the latest changes on the main branch by git pull

then checkout your branch by git checkout temp_branch

then merge git merge main

merge your changes, I usually use vscode to merge changes in the same files. I would suggest showing the error for further details.