CODEWITHSUNDEEP
gitgitlab
MatsuzakaSteven
MatsuzakaSteven

Reputation: 317

Git updates rejected because tip of branch is behind despite doing it after cloning?

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.

Upvotes: 0

Views: 193

Answers (2)

torek
torek

Reputation: 488629

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.

Upvotes: 0

nazir_cinu
nazir_cinu

Reputation: 66

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

Upvotes: 1

Related Questions