git rebase master then push origin branch results in non-fast-forward error

Question

I am trying on working on my featureA branch while keeping it up-to-date with the master branch.

Here is the scenario

git clone ssh://xxx/repo

git checkout -b featureA

$ git add file.txt

$ git commit -m 'adding file' 

$ git push origin featureA

meanwhile a couple new commits where pushed to origin master

git checkout master

git pull origin master

git checkout featureA

git rebase master

git push origin feature A
To ssh://xxx/repo
 ! [rejected]        featureA -> featureA (non-fast-forward)
error: failed to push some refs to 'ssh://xxx/repo'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

How can I rebase without forcing the server to accept it?

Lubricator

You can't rebase … rebase alters history and you have to force a push – Invention

Answer 1

You can't push after rebasing. The commits now have different SHA1s as their history is different. If the updated ref does not contain the old ref in it's ancestry, it's a potentially harmful operation and git won't allow it.

Your only alternate is to merge if you don't want to force.

Forcing is not so bad if you are working alone and don't need to have others committing to this branch.

Fielder

Thx @Adam! so in my case, do I keep merging with master to keep my featureA up-to-date with master, then push the changes to my remote featureA branch to keep them safe on our server? then when I am ready to merge featureA into master at some point in the future, I switch to master and do git merge featureA? – Lubricator

yes. You would only merge your feature into master with git checkout master && git merge feature. For day to day, merge as often as you like the other way around. – Fielder

Ok. Isn't it right that, for my day to day dev, when I will be merging master into featureA as follow git checkout featureA && git merge master && git push origin featureA to keep up with master, I will creating duplicate commits that master already has. This duplicate problem will especially surface when one day I merge master with featureA as follow git checkout master && git merge featureA right? – Lubricator

Yes you are correct. Of course you will have fetched before that. – Fielder

Answer 2

A short answer to your question: you can do the reverse by rebasing master against featureA (but don't push yet), and reset featureA to that point.

This is actually cherry picking the commits from master onto featureA, the downside is that you will end up with duplicate commits on two branches. It will solve your immediate problem (if that's your intention) but in the long run you should not be rebasing commits that have already been pushed to a remote branch. The best solution in your scenario is actually to merge.

Arbalest