Proper handling of merging between branches

[David Muir]

Just some background:

I have 3 main branches for a website I'm developing: trunk, staging, 
production.
trunk is the main development branch,
staging is for stuff that is nearly ready for production
production is for stuff that is live

Typically, the workflow is:
commit new features/bugfixes  to trunk,
merge to staging and test, (similar to edge.launchpad.net)
if everything goes smoothly, merge to production and deploy
otherwise fix in trunk and repeat

This works fine except for fixes that are critical.
In those cases, I create a hotfix branch off of staging (since trunk 
might not be production ready), fix and merge to staging and production.

I then need to get the change back into trunk, so I also merge the 
hotfix into trunk.
This works fine, but the commit includes all the merge commits in 
staging as well. So when I look at the log, it's a big jumbled mess.

What is the "correct" way to deal with this?
Should I make the commit to trunk, then cherrypick into staging?
Should I merge into trunk, then revert --forget-merges?

revert --forget-merges seems to work ok, when merging into staging 
again, but I'm guessing that there's a good chance of conflicts arising. 
Is the same true for cherrypicking?

Or is there another workflow that works better?

Cheers,
David