Check-ins to TFS2013 source control triggers CI build associated with separate TFS Git Repository

问题

I have a TFS 2013 server with several TFS team project collections and developers working happily against them. The project collections have a set of TFS builds associated, including relevant CI builds which trigger on each check-in, or in some cases, rolling (accumulated) check-ins. This process works flawlessly and has been the way of working for several years.

Recently, we've introduced a Git repository into the mix which also sits on our TFS 2013 server and appears as a node that I can connect to from my development environment when I connect to my TFS 2013 server. (i.e. it's not a local repo...)

This is being used by a different set of developers all using VS2013 and (mostly) the Git integration that is part of Team Explorer under VS2013.

This is all working fabulously EXCEPT..... team 1 are checking into TFS source control and triggering CI builds that I have set up against the Git repository?. Every single commit by any of team 1 is causing the build to trigger, despite the fact that they are modifying code that is NOT part of the Git repo, has never been and never will be! I've had to fall back to "manual" builds for now, which is not ideal because I really need to have a CI build to run tests.

In terms of the process template, we are using a slight modification to the standard Git build template which I think was derived from the work done by the ALM rangers - the modification is an extra step to trigger an InRelease deployment. I'm not sure if this is relevant or not, but in the interest of being detailed on the issue....

Anybody got any ideas of how I can fix this? In essence, I want to isolate the TFS and Git source control entirely when it comes to the builds that are triggered.