How can I use git rebase without requiring a forced push?
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
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.