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.

<

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.