title: How to cherry pick after having merged several changesets into one
body: <p>We are using TFS 2010 with the Basic Branch Plan outlined in the <a href="http://vsarbranchingguide.codeplex.com/" rel="nofollow" title="Branching Guide">Branching Guide on codeplex</a>
  for an internal web application.  We have just the 3 basic branches = Dev, Main (QA/Testing), and Release (Production).</p>
  
  <p>Because the app is an internal web application, we only support the single production release.</p>
  
  <p>We basically develop locally and once we complete a task (a bug fix or enhancement), we commit it to Dev.  We also generally do a Get Latest from Dev every day when we start work to pull down anything checked in by the other developers.  After some period of time (usually a week or two), we'll decide we have enough changes to justify updating the QA site and do a Merge All from Dev to Main and then deploy the merged Main branch to a QA server for testing.</p>
  
  <p>QA will then start testing the site, and after they're satisfied, we'll do a Merge All from Main to Release and deploy the merged Release branch to our production server.  Sometimes we even wind up doing multiple Dev-to-Main merges before actually merging everything on up to Release.</p>
  
  <p>Anyway, we've been using this strategy for a couple of months now and until recently everything was looking great.  We were able to hotfix Release if we ran into some critical problem in production and then just merge it backwards.  All was looking good.</p>
  
  <p>Then we ran into something we didn't know how to deal with.  We were given the directive of merging ONLY a single code fix on up from Main to Release (without merging everything else in Main).  Now since we didn't know this was coming, when the original changeset was merged from Dev to Main, it was merged along with several other changesets.  So when I went to merge from Main to Release, the only option I had was for the entire merged changset.    I couldn't "drill-down" into the merged changeset and pick just the one original changeset from Dev that I really wanted.</p>
  
  <p>I wound up manually applying the change like a hotfix in Release just to get it out there.  But now I'm trying to understand how you prevent a situation like this.</p>
  
  <p>I've read several articles on merging strategy and everything seems to recommend NOT cherry-picking changesets when you go to merge - to simple merge everything available... which makes sense..  but if you always merge multiple changesets (and they become one changeset in the destination branch), then how do you potentially merge only one of the original changesets on up to production if the need arises?</p>
  
  <p><strong>For example, if merging Dev (C1, C2, C3) to Main (becomes C4) - then how to merge only C1 from 'within' C4 on up to Release?</strong></p>
  
  <p>It makes me think we'd be better off merging every single changeset individually from Dev to Main instead of doing several at once.  At least then we could easily just take one on up from Main to Release if the need arises.</p>
  
  <p>Any recommendations/life lessons/etc. on handling branching/merging for this specific scenario would be greatly appreciated.</p>