You can manually checkout the code from each branch, make your changes subsequently to each branch, and checkin. Very carefully.
Much better is to have these 3 environments be branches of each other. (Typically you start with dev, and branch to the other 2 in turn). Then you can use the Merge functionality to merge (for example) your dev changesets directly to test, etc. At this point your Test modules (that need to be changed to match dev) are checked out, with the changes. Then simply commit the changes. Then repeat for staging and rinse. This is the suggested methodology for this common scenerio.
Two important notes:
- Even though TFS if very server-centric (compared to SVN, for example), this merging functionality happens on the client. You need to have each branch mapped to your machine. After the Merge process is completed, you'll have uncommitted changes in the target branch until you check in.
- In Microsoft's vision and in the example I give here, these branches are permanent. This was a change from my previous practice using SVN, where whole branches were created/promoted/retired all the time. In the TFS way, you create the Test branch and it remains, indefinately, the Test branch. It's never promoted; its changes are merged elsewhere.
Building is a separate action. You need to set up a separate build for each situation, though of course once you set up the first one the other two will be trivial. After your merge to staging, you'll then run the staging build. (From Team Explorer or in the Build menu). TFS is a bit heavy but once it is set up it does handle this situation very well, easy for a distributed team to merge and build quickly (with automated build tests, etc.).