This sounds like a job for continuous integration. If you have only one team mate this is not necessary (I assume this is a typo). If you have just one team mate you should merge every time you pull his changes. This won't take too long unless you are scratching in the same code the whole time, which is a bad idea to begin with.
With multiple team members you can use a continuous integration solution like
CruiseControl .Net: http://sourceforge.net/projects/ccnet/
Let the CI server constantly pull and build changes in the repos and do some testing there to ensure that changes are working nicely. This still requires you to merge as often as you pull changes, which is the better way.
The longer you keep two development branches seperate the more painful the merge will be. So you should focus on constant building, merging and testing as your workflow. The CI server could have IIS and you can test the final product there before it goes to production.
Of course if you have a code base that is easily broken by changes your life will be difficult whatever you do. In that case you should focus on refactoring.
Your users should never test individual branches, they should test the merged end result of the branches that will go into production.