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.

Solution 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.

Solution 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.

Solution 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.

Solution 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.

Solution 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

View more solutions

Comments

[Roy Truelove]

Thanks Dan. Could you let me know how the above should be achieved then? Is this just not a scenario where rebase applies?

[redhotvengeance]

If you isolate all of your work to topic branches, then it sets up a good scenario for rebasing. You rebase new pulled changes into your topic branch, but when you've completed that branch's changes, you merge the branch back into the main development branch.

[Daniel Pittman]

The problem is that you have published the branch - so you need to force push to the repository. You need to give up one of the two: publishing in the way you do, or rebasing. Sorry.

[Roy Truelove]

Sounds like rebasing doesn't work for this scenario. v1.0 isn't a topic branch, it's a release branch, so it will never die and has to be published.

[Roy Truelove]

Thanks CG, I think "use it to create fast-forward merges" is the key. It doesn't apply to my case above where I have two live branches - a development branch and a release branch, but it seems to apply very well for temporary topic branches that are only necessary for a limited peroids of time, and then can be deleted once they're merged. Thanks again.

[IsmailS]

I do understand this, but the original question remains. I think the actual answer is the one given by @Fabien Quatravaux

[joerx]

Well, you would still have to force-push the 1.0 branch, no? At least, that's how things tend to turn out for me all the time. Fabiens method would prevent that from happening.

[Javid Jamae]

I think this is the best answer for the specific problem in the OP. You create a temporary merge branch and rebase on that, then merge to master and push to origin. The temporary branch doesn't have to be pushed to origin. The only additional advice I would give is to have a develop or qa branch where the merged/rebased code can be qualified. After qualification, this code would then be ff-only merged into master. This allows for easy hotfixing if your qualification process takes too long. This is basically the "git flow" process.

[bwv549]

I have this same workflow (working from multiple computers/locations). So, let's assume you are working on a topic branch called 'mytopic'. As long as you always rebase a local throwaway branch (which is merely a branch of mytopic) onto "master" and then merge that back into mytopic, then you never have to force push. OP has a slightly different scenario, so in a case like that a force push might be necessary. However, I think that OP is rebasing the wrong way -- if he did it as I described then no force push would be necessary.

[Emil Vikström]

Rebasing master looks weird.

[redolent]

git is not without personality

[Max]

git merge -s ours origin/<branch> was what fixed it for us

[Siavas]

Thanks Fabien, great answer. For the ones of us that just want to integrate the changes into master and don't mind merging the feature branch itself, this can be done with: git checkout my-branch; git rebase master; git checkout master; git merge my-branch