Is the git "Golden Rule of Rebasing" so essential?

Question

I had a discussion recently with people absolutely opposed to a rebase strategy of feature branches on GIT. It seems to be an accepted pattern to use rebase only for local, private branches but never use it when there's several people working on a same feature & branch, as per this so-called "Golden Rule of Rebasing" (like explained here: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview )

I am just surprised there's a consensus on this. I worked 3 years with a full rebasing strategy, with about 20 developers working togeteher and guess what, it worked.

The process is basically:

• You create your feature branch, let's call it "myfeature", and push it to origin/myfeature
• Other people may check it out and work on it
• You may sometimes rebase it from master: from "myfeature", git rebase origin/master ; and then, yes, you have to push-force it.
• What happens when other people want to push their commits? They just rebase it: git rebase origin/myfeature . So they're now in fast-forward and can push it without forcing.

The only principle to respect is that the feature branch is owned by someone. The owner is the only one who can push-force.

So, I admit: as soon as there's a push-force, there's a risk to do errors. That's true. But there's also many ways to recover from errors, and really, in 3 years of development, I didn't saw a lot of force-pushing mistakes, and when it came to happen we always found a way to recover properly.

So, why is this "Golden Rule of Rebase" being so widely accepted? Is there something else I missed with that? I understand it requires a minimum of organization (every strategy requires some organization), but it works.

Answer 1

The problem with force pushing isn't about your feature branch and master, but about pushing your master to someone else's master - that synchronization is going to be overwriting their master with your changes, ignoring whatever is on their tip.

Considering this danger, there's a reason why you should not be using it at all unless things have screwed up and you absolutely, totally need to use it to effect repairs. A SCM system should not ever need to be forced like this, if it does its because something went horribly wrong (and my first approach in such cases would be to restore backups and repeat the operations to keep the history intact).

So perhaps the question is why are you rebasing at all? For 'clean' history when bringing features back to master? If so, you're throwing out all the good history concerning branching for purely style reasons. IMHO fast-forward merging is also not a best practice either, you should want to keep all history so you can see what you really did, not a sanitised version afterwards.

Answer 2

Rebase isn't essential, as you say it is mostly cosmetic. Sometimes it is a lot simpler then a merge. So it can have some "actual" value, but only "sometimes"

Improper use of rebase can be costly. Unlikely to lose data if you know enough to not panic and look up recovery procedures, but "hey nobody push for a while I have to fix ..." isn't great. Nor is having someone burn time on research recovery and testing when they could have been adding features or squashing bugs (or home with family).

With that trade off the results of "very few people do a rebase and forced push" isn't very surprising.

Some workflows can reduce the risk, for example reduce it to "zero as long as you remember which branches you are allowed to force and which you can't". In reality they might be safe enough to justify the risk, but folks frequently make choices based on larger folklore. Then again in reality the benefits are pretty small, so how tiny does the risk really need to be?

Answer 3

To add a different voice:

Yes, if you work as you describe, there is no problem with using rebase and force-pushing. The critical point is: You have an agreement in your team.

The warnings about rebase and friends are for the case where there is no special agreement. Normally, git protects you automatically, by, for example, not allowing a non-fast-forward push. Using rebase and force-pushing overrides that safety. That's ok if you have something else in place.

On my team, we also sometimes rebase feature branches if history has become messy. We either delete the old branch and make a new one with a new name, or we just coordinate informally (which is possible because we are a small team, and no one else works in our repository).

---

Note that the git project itself also does something similar: They have an integration branch that is regularly recreated, called "pu" ("proposed updates"). It is documented that this branch is recreated regularly, and that you should not base new work on it.

Answer 4

So, I admit: as soon as there's a push-force, there's a risk to do errors. That's true. But there's also many ways to recover from errors, and really, in 3 years of development, I didn't saw a lot of force-pushing mistakes, and when it came to happen we always found a way to recover properly.

The reason that Git users tend to avoid shared mutable history is because there is no automatic avoidance or repair of these problems. You have to know what you're doing, and you have to fix everything up manually if you mess up. Allowing exactly one person to do force-push is unintuitive and contrary to the distributed design of Git. What happens if that person goes on vacation? Does someone else temporarily own the branch? How do you know they won't walk all over whatever the original owner was doing? And in the open source world, what happens if the branch owner gradually drifts away from the community, without officially leaving? You could lose a lot of time waiting to hand off branch ownership to someone else.

But the real issue is this: If you mess up and don't immediately realize it, the old commits will eventually vanish after enough time has elapsed. At that point, the problem may be unrecoverable (or at least, potentially very hard to recover, depending on what your backup story looks like -- do you backup old copies of your Git repository, i.e. not just clones?).

Contrast this with Mercurial's Changeset evolution work (which, I should note, is not yet finished or stable). Everyone can make whatever changes to history they like, provided the changesets are not marked public. These amends and rebases can be pushed and pulled with total impunity, no need for a branch owner. No data is ever deleted; the entire local repository is append-only. Changesets which are no longer needed are marked obsolete, but kept indefinitely. Finally, when you mess your history up (which is treated as a normal part of your everyday workflow), there's a nifty command to clean it up for you automatically. This is the kind of UX people expect before they go around modifying shared history.