Even for small projects, perhaps with 1 (yes 1!) developer can benefit from using branching techniques in their Source Control system.  For example, imagine you have a custom software product that is in production and is also under development for the next version.  “Fine”, you say, I just work on the next version in the main codebase, what’s the big deal?  Well, what if, during the development time a critical production bug fix is required?  Hm…that rockin’ new feature you’re so excited to show your client is baked into the codebase?  Well, you *could* shelve the code, and pull down the latest.  That’s certainly one option, but still easy to make mistakes and check into the main codebase.  Branching can make a lot of sense for scenarios like this and TFS makes this easy:

1. Within Team Explorer, right-click on your project and choose “Branch…”
2. When presented with the dialogue, provide a name for your new branch.  Consider providing something meaningful (not just a “2” suffix ;)  ).  Click OK.
3. TFS will create a separate branch in Source Control and on your local disk drive if you choose the corresponding checkbox:
    
   
4. Now you can open your solution from this new branch. 
   1. You might also considering renaming the solution (right-click from within visual studio on the solution node and choose Rename).  Rename it to the same name as your branch.  This is helpful so when you have the solution open its more evident which branch you are working on, and this will show up in the “Recents” list in visual studio.
5. At this point, now you can conduct all the glorious coding for the next world-rocking version of your application (you know, the one that’s going to make your company bust out an IPO and make you an “insta millionaire”.  Equally important, now you can conduct production fixes back in the main branch of code.
6. TFS makes combining branches (known as “Merging”) pretty simple as well.  You can merge bi-directionally.  For example, if you had to make a bug fix in production, you’d likely want to merge from the main branch back into the “Next version” branch.  Of course, once you get the next version of code completed and it blows through QA squeaky clean, and into production, you’ll want to merge from the branch back into the main branch.   (you may want to wait a few weeks for a production release to stabilize prior to merging back into the main branch).
7. To Merge, right-click on the branch you want to merge (ex. the next version branch *into* the main branch) and choose “Merge…”.  The screens are intuitive, but refer to MSDN for any specifics on this. Here’s an example of the screenshots encountered when merging a production bug fix into a “future release” branch (mocked up horribly in Paint so as to not reveal real source code names):
   
   
   
   
   
   
   
   
8. Click next and sing the praise of merging.
9. At this point, the changes you merged will be pushed into the target branch, and in a checked-out state.  Just check in.
   1. Consider using labels as well.  You may find value in applying a label to your code to designate points in your code such as before/after merges or even branches.

EXTRA TIP:  If you already have a shelveset in a branch that you’d like to *move* into a different branch, check out this slick article.  Great stuff!

Enjoy!