9 hours ago, Josheir said:
Is it okay to use this entire solution?
Okay in what way?
You can store a bunch of source code just fine. Verify that your .gitignore is set up properly so you don't submit compiled objects and local configuration options, but in theory the tool sets those up properly.
You don't need to use Visual Studio manipulate the files in version control, it automatically detects when your project uses git by the presence of .git folders. If you use command-line tools, or if you use other tools like GitHub Desktop, or a git shell extension, Visual Studio figures out the current state and displays correctly. You can issue the commands directly in the IDE, or you can use the IDE as a viewer and then use other tools to implement the commands.
On my git-controlled projects I use Visual Studio for the diff tools because they look better than what most other git-based tools provide, but when it comes time to submit, to pull, or push, I will use other tools to do those steps.
If some of your projects are also hosted in another git project somewhere, there are fancy ways to make part of the directory tree reference a different repository. If you're going that route Visual Studio won't create the fancy subproject links for you.
9 hours ago, Josheir said:
Also, I would imagine there are big solutions by others using Github.
Big is relative. Git is a distributed version control system, and it is designed around text based source code.
Since text compresses nicely repositories are generally small. If you have a few megabytes of source code you may have 20+ megabytes of text files but your git repository might be one megabyte. As years of development time passes and you have hundreds of versions of the files, they grow based on however big the differences between the files happen to be.
Since it is distributed everybody gets a copy of the entire repository on their machine. Having a megabyte or two of repository on the machine usually isn't an issue when everything is text.
HOWEVER... If you store non-text resources in git, bad things start to happen. Differences between large files are also big. If someone accidentally puts object files or output executables in the repository, after a few builds and a few iterations the repository will grow at an alarming rate. A repository can grow to gigabytes in size, and those get cloned to every machine that uses them. Removing every reference with in a git repository and reducing the size back to something manageable is tricky, but there are tutorials and step-by-step instructions to walk you through it.
If you need to store version history of your non-code assets, Git (and any other distributed version control system) is the wrong tool.