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.