Git push after rebase

Question

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.

Suisse

So did you resolve all conflicts before trying to push? – Dilan

Possible duplicate of Git push rejected after feature branch rebase – Lowtension

It might be a better idea to use git push --force-with-lease: #52824192 – Helianthus

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.

Zulema

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 – Suisse

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. – Suisse

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 ? – Suisse

Yes to your last question. – Zulema

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. – Zulema

"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. – Antetype

I'd slightly argue with your last comment @Antetype 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) – Zulema

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 – Trippet

Answer 2

instead of git push --force you could use git push --force-with-lease which fails if any new commits were added to the remote branch

Checkrow

Correct use of --force-with-lease needs utmost care. In particular, beginners are usually taught workflows ("fetch or pull whenever you like") that totally irradicate its value. When that happens, it is identical to --force. – Contented