Git push after rebase

Question

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

git checkout master
git pull
git 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://[email protected]/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...

Answer 1

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.