So let's say I'm working in a development branch and I checked in a change, supplied a comment, and associated a work item. Now I want to merge that back to Main, is there a way I can have TFS merge know to associate that same work item and comment by default when I attempt to check it in?
Seems trivial but scale this out to multiple changesets a day and recording the work item numbers to reselect gets very tedious...
TFS has in my opinion a weakness on this one. All TFS-guides out there suggest that a multiple-branch scheme should be applied - which is absolutely reasonable (see here for a great reference).
Developers shall be working in 'playground' branches & once tests have succeeded, changesets are propagated into moree stable - more Release-near branches.
A somewhat duplicate question on that is this one.
According to the answers, an extension by J.Ehn could do what you 're after on the link-to-WI aspect. No evidence shows that the add-comments aspect is somehow included - yet this might not make tremendous sense (what should happen if the merge contains multiple commits from the \DEV-branch?). Still, it should be possible to fork this implementation and add the comments as well.
In the same question E.Blankenship provides with a rough road to another alternative.
In TFS, when you merge branches, the resulting Changeset is linked to all Changesets merged.
If you've merged a Changeset containing a file from Branch A to B, then in Branch B if you view history on that file it will show the Merge Changeset with a '+' next to it that allows you to tunnel to the original Changeset with comments and associated items. Why doesn't this auditing trail fulfill your requirement?
