Git rebase, fix conflicts, then push is rejected

Question

When I rebase, and there are conflicts which I then resolve, I get the following message:

hint: Updates were rejected because the tip of your current branch is behind

---

We have 2 branches:

• master is our base
• feature/fix-input-height (new feature to merge into master)

I am preparing feature/fix-input-height by rebasing master to locally resolve conflicts

git checkout master
git pull origin master

git checkout feature/fix-input-height
git pull origin feature/fix-input-height

git rebase master

---

• Conflicts arise
• I resolve them
• Then attempt to push the new feature branch

git push origin feature/fix-input-height

And end up with that rejected error message again:

hint: Updates were rejected because the tip of your current branch is behind

---

Everyone on stackoverflow suggests:

git push origin -f feature/fix-input-height

But forcing the push just feels wrong

Answer 1

Rebase works by copying commits. You start with, e.g.:

...--o--o--o   <-- master
      \
       A--B--C   <-- feature/fix-input-height (HEAD)

and end up with:

             A'-B'-C'  <-- feature/fix-input-height
            /
...--o--o--o   <-- master
      \
       A--B--C   [previous feature/fix-input-height, now abandoned]

But the other repository—the one that's not yours, that you ask your Git to git push to—still has the original commits. You don't have those commits any more. You have new and improved ones instead, but they don't know that. All they know is that you're asking them to throw away three perfectly good commits.

So they say No, I won't throw those away. Not unless you use a forceful command, rather than a polite request, at least.

That's why you need --force, or—better, though people don't use it a lot—--force-with-lease. Either way you tell them: Yes, I mean that you should throw out your commits. The difference between these two is that --force just says: Throw out your commits! Use this instead! Using --force-with-lease says: I think your feature/fix-input-height names commit C. If so: Throw out those commits! Use this instead! It will fail if someone has added commit D, that you don't have and therefore did not include in your rebase.

Answer 2

Torek's answer is undoubtfully the most insightful answer here but considering your concerns and the comments you added since then, your problem is more political than technical and you're right to worry about it.

The main concern here should be « Is anybody else working on feature/fix-input-height or is it a private branch ? »

If this "feature" branch is shared, then you shouldn't rebase since somebody else would still trying to applying changes to the previous reference. If it's fully private (that's one of the purposes the branches are for), then you may move it freely.

However, to make Git happy and to avoid your co-worker to manually reset their own local copy of your branch, what I would probably do is to preserve the transitive path from the old version to the new one. That is :

• Merge your branch on top of master, but choosing only the left side modifications when resolving a conflict, which would actually discard everything from your feature branch and leave master unchanged. But this still would introduce a merge point ;
• Replay all commits you actually want to move on top of your new feature branch.