We use the feature branch workflow, where developers will create their feature branches, do their work, rebase then when finished merge their changes to master. This allows us to have a nice commit history for separate projects and a fairly linear history on master without breaking any don't rewrite public history rules.
Now, sometimes we have bigger projects where multiple devs need to share a branch, so the initial developer would push the feature branch and others would pull it, then they would all create sub-feature branches and periodically push to it, instead of master. But if this has happened, I cannot do something like:
git rebase master someSharedBranch
But what if we had 30 commits from different developers on someSharedBranch and, when completely finished and ready to merge onto master, we wanted to slim this down to one or a few tidy commits. In our workflow, how is this possible without messing up public history? Do the same rules apply here, if it's certain that we want to change the commits then have them merged onto master?
