The intent is "don't rebase if you might have a downstream". You're welcome to rebase branches that you push as long as your workflow specifies that they are still volatile. For example, we push unfinished topic branches to our team repo as backup and to allow "passive review" (a pull request is "active review"). Comments at this stage are communicated by bitbucket line comments (or by email/chat) and are handled by amending the topic branch. This unmerged topic branch is rebased any time the author prefers to start from a later 'master' in exchange for re-testing the series.
When the topic is considered complete by the author, she either makes a pull request or merges to 'next' herself. Merging to 'next' signifies that another topic may depend on that branch.
In this workflow, an unmerged topic branch is roughly equivalent to a patch series on a mailing list, but doesn't require email client integration and degrades more gracefully with less disciplined commit factoring and less sophisticated tool use.
When the topic is considered complete by the author, she either makes a pull request or merges to 'next' herself. Merging to 'next' signifies that another topic may depend on that branch.
In this workflow, an unmerged topic branch is roughly equivalent to a patch series on a mailing list, but doesn't require email client integration and degrades more gracefully with less disciplined commit factoring and less sophisticated tool use.