I write this with an assumption about your strategy:
The answers below have a flavor that comes from assuming you want to propagate the repo-per-sln methodology. "Is it better for us to get everything into one git repo fast and separate later, or move to git piece by piece?" Is a real question to ask. I have only been part of 1 migration that did the whole hog, and the coordination effort was significant, because ppl went home on Friday using TFVC but came in on Monday using Git.
I bring this up because you mention that your boss
wants [you] to set up a proper Git repository to replace the existing TFVC repo
The use of "a proper Git repo" (singular) may change the way you need to thing about things, particularly on the AzDO CI/CD front.
On to (my version of) the answers:
How do I get only one of these solutions into a single Git repository
If the solutions are truly separate, and you don't have dependencies on other solutions, then create a directory with the name you like for your repo and give it the good ol' copy-paste treatment. Then you can init a git repo there (don't forget to include a good .gitignore file for VS projects) and commit the initial changes. Then you can setup the AzDO project repo as the remote to push to.
If you're new to Git, you may want to init the repo on AzDO and clone locally rather than manually setting up AzDO as a remote for a repo you created locally. Then you can still use the hammer (read: copy/paste) to get your TFVC code into your new git repo.
If the solutions are inter-dependent with project and assembly references, you'll need to really think about strategy here. In my latest migration, we have opted to use NuGet packages to deliver components that are shared across multiple services or products. In cases like this, you'll probably want to start with the shared code. Getting that stuff in its own place, and implementing a strategy for delivery is a good place to start and will give you a real idea of what the migration is going to take.
Which tools should I use in this case?
I tend to use Git Bash for most things like this, but "to each his own". As @DanielMann mentioned, your tool will be defined by what you really need history-wise. I have sided with his opinion in all of my migrations so far. "Let the past be the past." This latest migration has also opted to abandon the on-prem Team City build configurations in favor of a pure AzDO implementation for SC >> CI >> CD.
2) TFS has three branches: dev, main, and master (which are parents of the solution folders). How do I get just one of these branches to be brought over into Git (ie. I just want Master brought over)? Must I include all branches?
I'm going to reverse the order of these 2 questions:
Must I include all branches?
No. TFVC tracks files, so each branch has its own piece of the file system.
2) TFS has three branches: dev, main, and master (which are parents of the solution folders). How do I get just one of these branches to be brought over into Git (ie. I just want Master brought over)?
Again, use the hammer. You should create a new area of your local file system to represent the repo(s). For example: my repo container is c:/src/ then I have the directories representing each individual repo c:src/r1/ c:src/r2/ ect. (note: my names are way better than what's in the example). Once you have this, get latest from the desired TFVC branch and hammer away.
Possible headache
Make sure you can get other developers to stop making changes to the code you're migrating. If you're setting up an AzDO CI/CD pipeline too, you may end up making changes to the projects to get that working. If devs are still changing the source you're working on, you will want to echo your changes in TFVC for them to write on top of, else you'll be in merge hell when you try to hammer the new changes back into git.
