1

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?

Charlie
  • 33
  • 4
  • You didn't integrate the remote changes. All you did was rebase on `origin master`, what you properly want to do is rebase on `origin/main:temp_branch`? – Andreas Louv Oct 08 '21 at 13:45
  • `origin main` :sighs: – Andreas Louv Oct 08 '21 at 13:45
  • Integrate the changes, and eventually as also mentioned in the linked issue, you'll need to force it up someway, either by `--force`, or one of the more restrictive alternatives, `--force-with-lease` or `--force-if-includes`. – Andreas Louv Oct 08 '21 at 13:47

2 Answers2

0

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

Then to push you can simply use:

# the first time you push
git push
# or for subsequent pushes after a rebase (or amend of a commit)
git push --force-with-lease

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.

TTT
  • 22,611
  • 8
  • 63
  • 69
  • I have tried to understand and to my best knowledge. I tried to recreate the scenario and I had follow these steps. After I did the second change in my local repo. I did `git fetch`, `git switch temp_branch` - response - Branch 'temp_branch' set up to track remote branch 'temp_branch' from 'origin'. `git rebase origin/main` - response - Successfully rebased and updated refs/heads/temp_branch. i did `git status` and it showed as you said and then I did `git checkout main` and `git merge temp_branch` after this when I used `git push origin main:temp_branch`, Did I do it correctly? – Charlie Oct 09 '21 at 21:29
  • I want to have the changes of remote main when pushing to the remote temp_branch next time – Charlie Oct 10 '21 at 07:56
  • @Charlie it's not clear to me what your process is for getting code merged into `main`. Do you use PR's on GitHub and complete them to merge into `main` or are you supposed to push the `main` branch yourself? – TTT Oct 11 '21 at 14:04
  • @Charlie The last 3 commands you did in the comment probably weren't necessary. After you checkout `main`, `git merge temp_branch` will fast-forward merge and make your local copy of `main` identical to `temp_branch`. And then your last command pushes your local copy of `main` to the remote copy of `temp_branch`. You could simply have just pushed out `temp_branch`, and if you did already, then the last command would have no effect. But it didn't hurt anything. Depending on your branching strategy though, I might leave your local copy of `main` alone though to avoid confusion. – TTT Oct 11 '21 at 14:18
0

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.

deirdreamuel
  • 609
  • 8
  • 11