0

Error message:

hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Let's say that I have a work branch and a master branch

I have just cloned the repository from gitlab and all I want to do is just to

git push origin work:master

to push all the contents of master

how do I solve this?

I have tried doing git pull and it does nothing and I cannot do -f push as the master branch is protected.

MatsuzakaSteven
  • 197
  • 1
  • 16
  • `git rebase work origin/master` – Cory Kramer May 07 '20 at 13:41
  • Does this answer your question? [Updates were rejected because the tip of your current branch is behind](https://stackoverflow.com/questions/39399804/updates-were-rejected-because-the-tip-of-your-current-branch-is-behind) – Daemon Painter May 07 '20 at 14:21
  • @DaemonPainter That's a bad dup because the accepted answer talks only about `git push --force` and the OP doesn't want force-pushing. – phd May 07 '20 at 14:22
  • @phd, but I feel like the question is actually explaining why the issue was caused in the first place. If that's true, the answer is "you must do a force push onto master". Which is not possible in GitLab due to GitLab limitations of "protected branch". – Daemon Painter May 07 '20 at 14:26
  • @DaemonPainter Well, I don't see why the repo needs force-pushing instead of `git pull` (`git pull origin master` probably) or `git fetch` + `git merge` or `git rebase`. – phd May 07 '20 at 14:29

2 Answers2

1

Try the following command in order:

git fetch origin master
git rebase origin/master
git push origin master

Hopefully, you don't get any conflicts during rebase or else it has to be resolved manually

nazir_cinu
  • 66
  • 1
  • 6
0

git push origin work:master means call up the other Git at origin, offer them any commits I have on my work that they don't have, then ask them to set their master to match my work. That's not wrong, but it's a bit unusual: usually we ask their Git to set their $name (for any $name) to match our $name. In this case we'd normally ask them to set their work, not their master.

If you just cloned from them, how did you set up your name work? Presumably their Git recommended that your Git create a branch named master, not one named work. If you subsequently ran git checkout work and your Git created your work based on your origin/work that was a copy of their work, that would suggest that their work is behind their master.

(It's possible that the Git over on origin is set up to recommend that your Git create a branch named work based on their work, in which case, your Git will have done that.)

In any case, this means that the tip commit of your work is behind (but possibly also ahead of) the tip commit of their master. If you force them to set their master to match your work, they will "lose" some of the commits off the end of their master branch. That's usually a bad thing, and hence it's rejected by default.

If that's a good thing for you today, you can turn your polite request If it's OK, please set your master to _____ (fill in the blank with the hash ID from your name work) into a forceful command: Set your master to _____! (fill in the blank the same way). If you have permission, they will obey the command, and thereby lose the commits that they had that were "ahead of" your work.

If you don't want to remove commits from their master, figure out the arrangement of commits that you'd like to have, and use git rebase or git merge to copy or combine any work commits you have that they don't, into an arrangement that won't cause them to lose their commits.

torek
  • 448,244
  • 59
  • 642
  • 775