29

I know this has been asked before but i cant seem to wrap my head around this thing...

git checkout master
git pull
git checkout feature
git rebase origin/master

then resolve all the problems....
Try to push - not gonna happen...

git is really telling me that after doing a rebase ( dealing with n:ths of conflicts )

i have two options, use --force which seems risky and stupid.

or pull again and deal with the merge conflicts again... and end up in same situation?

error: failed to push some refs to 'ssh://git@git.zzz.com/yyy/xxx.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I have locally: feature branch, master ( up to date )

and remote: featureBranch ( which is ahead now ?! ) and master.

I just want to update my feature branch so it's even close to version on master... Why is git like this...

I've read many threads about this, and the only solution seem to be to use --force

This dosent seem like an solution at all, for me, for such commonly used tool...

padawin
  • 4,230
  • 15
  • 19
Clomez
  • 1,410
  • 3
  • 21
  • 41

1 Answers1

43

There is nothing wrong with git push --force on principle.

What it does is to replace the remote head of your branch with your local.

There are two cases, one where it is fine to push force, and one where it is not fine at all:

If you rebased (and therefore created a new chain of commits for your branch), your branch and the remote diverged, which is to be expected. And you made them diverge on purpose. For example your branch was not up to date with master, so you rebase it to "move it" on top of master (technically, the commits are recreated from the new base, in this case master but effectively it looks as if it has been moved). So you know that they diverged and that your local version is the correct one. In this case it is fine to tell git: "Take this version, discard the one you have".

However, if you work with people on a same branch and one person pushes the branch with new changes while you make your own changes, then when you will want to push, Git will also tell you that the your local branch and its upstream diverged, and so you should pull first and so on. In this case it is important to not push --force otherwise your colleague's work will be erased, and he/she will be pretty upset. So in this case you must indeed pull first (I would recommend pull --rebase to not create a merge commit, and keep your history cleaner, but that's very subjective), then push (and after pulling, no --force will be needed).

Bottom line is, know what git push --force does, know when it is ok to overwrite the upstream with your local (you can then push force) and when it is not ok (you need to pull).

And to come back to your original case, you rebased your branch, so it diverged (by definition), so if you work alone on the branch or if you made sure that nobody pushed anything on it in the meantime, git push --force is what you need.

padawin
  • 4,230
  • 15
  • 19
  • 3
    Thank you, i still think this is waaaay too convoluded tho.. So since im going to force replace the current featureBranch, that means that if anyone(else) is actively working with featureBranch, and has changes, yet to be pushed to remote. All these "not-yet-pushed" changes will be lost(forever) since there is no featureBranch anymore? All i want to do is get my branch up to date with master oh my god – Clomez May 14 '19 at 11:16
  • And the other way is to FIRST pull, then make rebase with that pull (including changes anyone else made that were pushed while i corrected conflicts) replacing the remote-head? EDIT: i understand that bottom line is understanding what commands do, but thats where i hit problems.. every 'learn git in 15min' guide ive read seems to be more or less bullshit. – Clomez May 14 '19 at 11:18
  • And as there is no changes coming from anyone else, nobody should be working on this branch then it should be safe to just git push --force ? – Clomez May 14 '19 at 11:22
  • 1
    Yes to your last question. – padawin May 14 '19 at 11:26
  • 2
    If you work with someone on a branch (which is an arguable thing to do, but that's a workflow question), I'd suggest the following: first (before rebasing) make sure that your branch is up to date with the remote (aka, you have everything which is on the remote), then rebase it to do what you need (rework it, have it on top of master...), then finally push back force. And keep your coworkers in the loop. – padawin May 14 '19 at 11:29
  • 1
    "*So since I'm going to force replace the current branch, that means that if anyone else is actively working with the branch and has not-pushed changes, all these "not-yet-pushed" changes will be lost since there is no branch anymore?*" Not necessary, they can pull with merge or rebase thus preserving their changes. "*All I want to do is get my branch up to date with master*" That the problem. To avoid situation you've just described you must never edit (amend, rebase, filter-branch) pushed commits or move branch pointers (reset). Consider pushed commits/branches carved in stone. – phd May 14 '19 at 11:30
  • 2
    I'd slightly argue with your last comment @phd and would say that any shared branch, or base/parent branch (e.g. master) should be left untouched once pushed. *When you feel enough at ease*, it does not matter for personal feature branches and I'd encourage to push them asap to not have them locally, but to still not hesitate to rework them (while they are only personal feature branch. Once they are merged, they should be considered as fixed) – padawin May 14 '19 at 11:33
  • Thanks a lot! I was trying to delete an accidentally added large file using rebase, and then when I tried to push, it wasn't working and I didn't have permission for forced push.. tried `git pull --rebase` followed buy a `git push` and worked like a charm! :D – Sreekiran A R Aug 24 '22 at 19:32