git rebase and sharing a feature branch?

Question

Based on this: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase

git rebase will make it possible to maintain a linear history (a merge "always" results in a fast-forward)

But if I want to enforce a linear history and require developers to always rebase their feature branches on latest master will that not result in collaboration/sharing feature branches going out the window? See:

Don't rebase public history

so is it possible to enforce linear history using git rebase and at the same time allow multiple developers to contribute to the same feature branch?

Or will git rebase imply that there can only be one owner of a feature branch?

Answer 1

"Don't rebase public history" is a good starter rule. More comprehensive advice is, if you're going to rebase a shared branch, you need the agreement/cooperation of everyone who has a copy of it.

(At this point usually someone likes to jump in and object that sometimes getting everyone's consent isn't practical. What they're trying to say is that the rule is too strict; but that's like saying the speed of light is too slow because I need to travel faster. The correct analysis is that yes, sometimes you can't get everyone on board; and in those cases you shouldn't rebase. Hence the simplified "don't rebase public history". If you don't have the cooperation of everyone who shares the branch, it's unsafe to rebase the branch and your attempt to do it could easily end up being accidentally undone. But I'm digressing...)

So, if it's a team norm that after people have collaborated on the branch, and you're ready to merge it, you're going to rebase it and everybody is going to throw away their local copy of the branch, then it's ok - you have everyone's cooperation with the rebase.

But that doesn't necessarily mean it's a good idea. The marketing literature for rebase likes to talk up linear histories as "simpler", but leaves out that your shiny new linear history is made mostly of code states that have never been tested (which can mess up attempts to bug-hunt with bisect). Some projects find value in preserving the commit topology, so e.g. they can look back on a feature branch as a unit rather than just having to figure out that commits K through N happen to have been a feature branch at one time.

But all that's up to you/your team. If you think a linear history is what suits you, then yes, it can be done even when feature branches are shared, so long as you'd discard them after merging anyway (which... why wouldn't you?).