I'm part of an organization that is unfortunately using TFS/TFVC for source control. My small team been tasked with doing a sort of "proof of concept" run with git, but we have to be able to push our changes into TFS. Luckily, git-tf and git-tfs exist. However, our TFS repository is one monolithic repository with 20+ different projects/applications. The proper way to do this in git would be for each project to be its own git repository. I know that I can check out an individual project from TFS using the bridges with git-tf, and if we were permanently converting to git, it's what I would do.
What I'm concerned about is if we still need to push back to TFVC, if I check out each project as its own git repository, will TFVC become confused when we push the changes back as each project is changed independently? That is, if I check out Project A from changeset 123 and Project B also from 123, make changes in A and then push those back up to TFVC as changeset 124, will TFVC think there's a merge conflict or other issue when we later make changes to B and push them up since it's all one big repository under TFVC.
Does either git-tf or git-tfs handle this properly? Or do I need to just check the whole TFS repository out as a single git repository and work with that as is? Or in this case would it maybe be better to check out the various TFS projects into a single local workspace, and use git to create repositories without using the git-tf bridge, and check changes back into TFS as if they were edits made in the workspace directly (basically ignoring all the git history and commit logs and just using it for local change tracking)?