3

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.

Improve this question
1
  • It might simply work out if you create a specific task for merging process that you could associate whenever you check in a merge. Then it's quite easy to see what have been modified having a look at the associated changeset.
    – MaxSC
    Jul 4, 2013 at 21:38

1 Answer 1

Reset to default
2

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.