Why does TFS allow a single changeset to affect multiple branches? If there isn't a very good reason, can this be prevented?

Question

It has recently happened that a coworker, after completing some minor changes to the Stable branch of our solution, accidentally checked-in some of his unfinished work on the Development branch as well. TFS bundled it all up as a single changeset.

While the mistake was easily detected and fixed, I feel like I am missing something critical here. Why would TFS's "Pending changes" page allow you (and, worse, offer by default) to create a single changeset containing everything you've done on every branch?

It seems to me that a changeset should consist of changes to one and only one branch, so you can more effectively manage/merge/rollback them as necessary, without affecting other branches. If you have been working on multiple branches at the same time, upon checking-in it should ask you to insert multiple descriptions, and create multiple changesets as a result.

Assuming my reasoning is at least valid (if not necessarily universal), is there a way to configure TFS so that users may not check-in changes to more than one branch at a time?

EDIT: Failing that, I would appreciate a way to at least set the 'Pending Changes' page to put all changed files by default in the 'Excluded' section, so users will need to manually include them before checking in (which would help them notice any accidental changes).

Answer 1

Best practice: A developer can check in pending changes limited to a given folder/branch by right-clicking the folder, choosing "Check in pending changes". For that check-in action, the "Pending Changes" view will temporarily "exclude" any changes made outside of that folder/branch until you complete the check-in.

Can it be prevented: Per Microsoft, there is a premade Check-in Policy option known as "Enforce check-in to only contain files that are part of current solution". This may work for you, assuming you use "Solutions".

Why is this allowed: I suppose it's just how TFS was designed. I'd suspect it's to do with the treatment of branches as folders, and allowing check-in's across folders leaks into allowing check-in's across branches.

Answer 2

I can think of some scenario where this could be useful, like applying a critical fix on both release and main branches and merge is not an option.

What you can do to minimize the risk is to reduce the scope of developer workspaces as suggested by Jesse in Check-in each project separately?.