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.

Answer 3

You have to force push if you rebase, and you have already published your changes, right?

I use rebase a whole bunch, but I either publish to something private where a force push doesn't matter (eg: my own clone on GitHub, as part of a pull request), or I rebase before I push for the first time.

This is the heart of the workflow where you use rebase, but don't force push much: don't publish things until they are ready, don't rebase after you push.

Answer 4

I think there's a good use-case for this rebase-then-force-push pattern that's not a result of a mistaken push: working on a feature branch by yourself from multiple locations (computers). I do this often, since I sometimes work at the office on my desktop, and sometimes from home/customer-site on my laptop. I need to rebase occasionally to keep up with the main branch and/or to make merges cleaner, but I also need to force-push when I leave one machine to go work on another (where I just pull). Works like a charm, as long as I'm the only one working on the branch.

Answer 5

Here's what I use (assuming your branch name is foobar):

git checkout master              # switch to master
git rebase   foobar              # rebase with branch
git merge -s ours origin/master  # do a basic merge -- but this should be empty
git push origin master           # aaand this should work

Answer 6

tl;dr merge with shared branches, rebase with individual branches. --force-with-lease is a safer alternative to force and should help you achieve said git nirvana without the destructive nature of force.

A general rule of thumb that I've seen work for various teams' workflows is to use merge for shared branches (I.e., master or develop) and use rebase when working on your own feature branch. Here is a typical life cycle of a feature branch

git checkout master
git checkout -b new-feature
git commit -am "commit new work"
git push -u origin new-feature
# have code reviewed, run CI, etc.,
# meanwhile master has new commits
git checkout master
git pull origin
git checkout new-feature
git rebase -i master # -i for interactive rebase allows you to squash intermediate commits
git push --force-with-lease
git merge master

A plain english version of what we've done here:

1. Created a new branch off of master
2. Done work on branch and pushed to remote
3. rebased off of master
4. Push work to remote with force-with-lease
5. merge into master with a very clean git log, reducing clutter from multiple merges from our shared branch to get our branch "caught up" with the latest master (shared branch)

The 4th step is REALLY important and one of the main reasons I started advocating for the use of rebase. force-with-lease checks the remote to see if any new commits have been added. If your git push was proven to be destructive it won't push!

I hope this gives someone more confidence to use rebase.