How can I use git rebase without requiring a forced push?

Question

In an attempt to achieve git nirvana, I'm spending the day learning how to leverage rebase for situations where I currently merge.

When running through what I consider to be a git 101 flow (which I spell out below), I have to push --force when pushing my changes back to the origin.

I'm not the only one - I know that this is covered ground (see 1,2,3,4,5), and I understand the technical reasons why a force is necessary. My issue is this --- there are many (many) blog entries singing the praises of rebase and how it's changed their lives (see 1,2,3,4 to list a few), but none of them mentions that push --force is part of their flow. However, nearly every answer to the existing stackoverflow questions say things like "yeah, if you're gonna rebase, ya gotta use push --force".

Given the number and religiosity of rebase advocates, I have to believe that using 'push --force' is not an inherent part of a rebase flow, and that if one often has to force their pushes, they're doing something wrong.

push --force is a bad thing.

So here's my flow. In what way could I achieve the same results without a force?

Simple Example

Two branches:

• v1.0 - a release branch, contains only patches
• master - everything for the next major release.

I've got a few patch commits and a few commits for the next release.

I'd like to incorporate the patches into my master so that they're not lost for the next release. Pre-enlightenment I'd simply:

git checkout master git merge v1.0 

But now I'm trying

git checkout master git rebase v1.0 

So now I'm here:

Time for:

git push 

No dice.

Answer 1

Rebasing is a great tool, but it works best when you use it to create fast-forward merges for topic branches onto master. For example, you might rebase your add-new-widget branch against master:

git checkout add-new-widget git rebase -i master 

before performing a fast-forward merge of the branch into master. For example:

git checkout master git merge --ff-only add-new-widget 

The benefit of this is that your history won't have a lot of complex merge commits or merge conflicts, because all your changes will be rebased onto the tip of master before the merge. A secondary benefit is that you've rebased, but you don't have to use git push --force because you are not clobbering history on the master branch.

That's certainly not the only use case for rebase, or the only workflow, but it's one of the more sensible uses for it that I've seen. YMMV.

Answer 2

@CodeGnome is right. You should not rebase master on v1.0 branch but v1.0 branch on master, that will make all the difference.

git checkout -b integrate_patches v1.0 git rebase master git checkout master git merge integrate_patches 

Create a new branch that points to v1.0, move that new branch on top of master and then integrate the new version of the V1.0 patches to the master branch. You will end up with something like :

o [master] [integrate_patches] Another patch on v1.0 o A patch on v1.0 o Another change for the next major release o Working on the next major release |  o [v1.0] Another path on v1.0 |  o A patch on v1.0 | / o Time for the release 

This way to use rebase is recommended by the official git documentation.

I think you are right about git push --force : you should only use it if you made a mistake and pushed something you did not want.