Git Workflows: Rebasing Published/Shared Branches

Question

Our team at work has enthusiastically adopted a rebase workflow, but we might have gotten a little carried away, which is the point of this question: you be the judge.

Answer 1

This sounds like it's overly complicated and won't scale well. It's probably a heck of a lot simpler just to merge master into your feature branch periodically, and then when it comes time to merge back into master, then you can do the rebase first (to remove the intermediate unnecessary merge) and merge back into master (presumably with --no-ff to produce a merge commit). This only requires one person deal with the rebase, and they don't have to do any coordination because nobody else needs to force-update anything (because, presumably, the branch is going to be deleted after it's merged, rather than kept around in a rewritten state). You may also decide to skip the rebase entirely and just leave the intermediate merges in place, which would more accurately reflect your development workflow and remove the risk of producing commits that don't actually build.