I’m new to TFS branches, and have opted to set up a Dev and Main branch (ultimately there will be release branches too). I’m using TFS2012. My understanding is that I will work on the Dev branch on a day to day basis. When a bug is fixed or a user story is completed, I will merge Dev to Main, build, and give that to the tester.
In Dev I have a policy to ensure that check-ins are associated with a work item. However when I merge from Dev to Main, and check-in that merge, what would I associate that check-in with, if anything?
The reason I ask is because I’m wondering how someone could find out what changes went into a particular Main build? It’s obvious in Dev, as you’ll see the associated work items in the build output. But there will be no such history in Main, unless I associate the merge check-in with some sort of work item. The tester needs to know what’s gone into a particular Main build, but how? Is it a manual process, where the developer simply gives him a list of changes that have been merged into Main?
I’ve read the MS branching/merging guidance, but it doesn’t really shed light on this kind of thing.
1
As Max said, you could create a task specifically devoted for the merging Dev into main process and then track which changesets have been associated with that task.
Also, you can read on every build journal the list of the changesets used for the build.