I'm doing this:
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 telling me that after doing a rebase, 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 the 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.
I've read many threads about this, and the only solution seem to be to use --force
This doesn't seem like a solution at all, for me, for such a commonly used tool.
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.