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)?
Yes, you can create multiple Git Repositories per TFS Team Project. This is just the same as in one Team Project to rule Many Git Repositories.
More details you can take a look at this link: Many Git Repositories, but one Team Project to rule them all
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 TFS as changeset 124, will TFS 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 on TFS.
TFS will only detect the corresponding files and codes, just as jessehouwing commented. you'll only get conflicts when files have been changed in both git repositories. Such as a file in changeset 123 have version a, and edited in changeset 124 with version b from git rep1. And this file also check out with version a for repB. If you didn't change it to version b in git rep2. When you push changes you will certainly get the conflict.
git-tfs is a two-way bridge between TFS and git. Such as using
git tfs checkintool command to commit through the tfs checkin window. So the result is the same as using multiple git repositories in one GIT team project. The only difference is one push commits, another check in changes. All of three methods you have mentioned above should be work. The best one is using git-tfs which will tracking all history.