I try to avoid horrible things like that at all costs. Sometimes it's easy, sometimes not so much. The rule of thumb is that all branches (unless there is a really, really good reason to do otherwise) are created from the master, and are rebased before the push (by the person, who did the development in this branch), and if there are conflicting changes, before the merge as well.
With the absolutely rarest exceptions all patch releases are done in the same manner as the regular ones, i.e. from the HEAD of master. History must be as linear, as possible.
So there are basically 2 general cases when you really need to share a commit. In the first, you find out in your branch there's something to be fixed, which you know I already fixed in mine, in the commit X. In this case it's better if I reorder commits in my branch so that X is the first one, create a new branch with X, which then is merged in a proper manner. You can rebase then.
Second case is when 2 people with different skill-sets or responsibilities must work on something that "from the above" looks like the same piece of functionality. Then, however hard you may try, it all turns up much messier and they will end up needing to share branches (so they cannot rebase them) with multiple commits. In this case I name one of them responsible for changes made within this task as a whole, so when the work is finished the second (3rd, 4th,...) person doesn't touch the branch(es) in question any more, and the first one might rebase and clean up it as needed.
With the absolutely rarest exceptions all patch releases are done in the same manner as the regular ones, i.e. from the HEAD of master. History must be as linear, as possible.
So there are basically 2 general cases when you really need to share a commit. In the first, you find out in your branch there's something to be fixed, which you know I already fixed in mine, in the commit X. In this case it's better if I reorder commits in my branch so that X is the first one, create a new branch with X, which then is merged in a proper manner. You can rebase then.
Second case is when 2 people with different skill-sets or responsibilities must work on something that "from the above" looks like the same piece of functionality. Then, however hard you may try, it all turns up much messier and they will end up needing to share branches (so they cannot rebase them) with multiple commits. In this case I name one of them responsible for changes made within this task as a whole, so when the work is finished the second (3rd, 4th,...) person doesn't touch the branch(es) in question any more, and the first one might rebase and clean up it as needed.