git rebase on long-lived (remote) feature branches

Question

Background: We use github for our project and I work on my own fork of our main repository. We use rebase instead of merge to avoid large merge commits.

Scenario: The way I want to work is like this:

1. When implementing a new feature, create a local branch of my fork's master and put in my changes there. I and others in the group make many small commits, so there will almost always be multiple commits that affect the same file on the branch.
2. Push the local branch to my fork so I have a remote copy of what I am working on (I don't want to have all my changes lost if my laptop dies or is lost. I try to do this at the end of each day).
3. If it takes a long time to finish the feature, I occasionally rebase on my fork's master to make sure that there has been no changes that could break my feature. This usually works ok.
4. To keep the remote copy of the branch up to date, I push my local branch to that after the rebase.

Problem: Step 4 is where I get the problems. I almost always have to deal with non-fast-forwarded commits and use git push --force.

I've looked at

Git: how to maintain permanent parallel branches

How to maintain (mostly) parallel branches with only a few difference

and haven't found a way to make my workflow work. Doing a google search on git workflows mostly returns results that assume that you all work on local branches and don't keep a remote copy on github (e.g. http://nvie.com/posts/a-successful-git-branching-model/).

I'm relatively new to Git, so I'd like to know if I am missing something here. I'd like to be able to do step 4 without a --force. An alternate workflow that still allows me to use rebase instead of merge and keep a remote copy of my local branch would also be very useful.

Answer 1

git push --force is a fact of life when dealing with rebase and remote branches, because git push won't do a non-fast-forward push without it. Most things in git assume that history is only appended to, never edited, and rebase breaks that assumption, so you have to do some pretty wonky things to make it work.

We used to use a rebase workflow very similar to the one you describe, but eventually switched back to a merge workflow after a while. Rebasing gives you a nice, pretty, linear history, but has many drawbacks, such as requiring --force, losing the ability to see the state of a branch before you merge in master, et cetera.

As Amber mentions, rebase makes it very difficult to work with other people on the same branch -- before git push --forceing, you have to look at the status of the remote branch to see if someone else has pushed to it first, and pull --rebase that in, then git push --force. Even this has a race condition - if someone else pushes just before you push --force, their changes will get overwritten by yours.

Answer 2

If you're rebaseing, you will always have to --force when you push, because rebase rewrites history. That's simply how it works. Rewritten history isn't going to fast-forward on top of that same history by definition.

The alternative is to merge instead of rebaseing. You could use your exact same workflow, except with merge instead of rebase, and you would not have to force push.

If no one else is using your remote branch aside from you, then using --force isn't inherently bad. If other people are using the remote branch, you should probably use merge anyway.