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.
Best Answer
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.