I have a Solution for Visual Studio 2017.  However, it has 82 projects and I won't be using all of them.  They aren't huge projects.  I want to use the following link: https://blogs.msdn.microsoft.com/devops/2013/02/06/create-connect-and-publish-using-visual-studio-with-git/  to start up my own personal Github repository.  Is it okay to use this entire solution?  I am thinking the consideration would only be the initial PUSH, and therefore it is okay.  Also, I would imagine there are big solutions by others using Github.  It might be nice to have some of these tutorials together on the server too. 

Thank you,

Josheir

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.

18 hours ago, Josheir said:

However, it has 82 projects and I won't be using all of them

What I did for our engine is to split code into logical packages, place them "as is" on GitHub (without any solution file, project file or any other VS related file) and add two descriptor scripts to them. The heart of our projects are self-written pipeline tools and first and foremost the Shell. This tool is an extension based program that could handle commands and load C# assemblies as command modules so we could just use and maintain our pipeline as custom as possible.

From my hobby project announcement there is already our setup tool Spark existing that isn't more than some more clever self-extracting archive file. It extracts the initial source code needed to run Shell and coresponding setup scripts, compiles those code to an executable and starts directory setup.

Last step is our packager. This Shell module is used to determine existing packages in the directory by detecting one of the files stored along with the code and also lists available packages and offers commands to install, update and remove packages and their dependencies.

Long story short, I have created an environment that lets us manage our projects in a way that we could decide for those parts of our code base and tools needed to work on each project in a flexible way and have any VS relevant file auto generated then.

This made our workflow way more efficient in case of designing functionality rather than spending time to manage and maintain our projects code base

On ‎9‎/‎11‎/‎2018 at 6:56 PM, frob said:

Okay in what way?

Memory space at the repository, and the amount of time it takes to push/pull.

Hi Josheir.

If you have a lot of large, non-text files and don't want or can to store them somewhere else: Look at git lfs.

If you have just the code files in the actual repository, the size shouldn't be a problem (normally).

How many lines of code (without third party packages, modules etc.) do you need to store in git?

12 hours ago, ChaosEngine said:

Why wouldn't you add the solution or project files? The project file is essentially the "build script" for the assembly. That information is just as critical as the source code itself. 

Because VS Project files could be reduced to some production and some generator informations so I could make way smaller build scripts that just determine what files contain in the project and so on and don't need to maintain project files for several VS versions or other tools when developing cross platform boundaries. It is possible to generate such projects files with a set of default settings and only this set of information

let $<variable> be '
{
  "name" : "",
  "type" : "[cpp | csharp | project]",
  "dep" : [  ],
  "source" : 
  [
    
  ]
}'

I run this simple (in our Shell Tool language written) script to have a project (cproj/csproj) file generated and also pack them into a solution to launch with VS automatically. Because I like convinience, there will also be .filter files created so I get the sub-folder structure for every module in VS too

The size of those compressed text files is nominal.  They often end up <10% of their original size, and it only stores the differences between the files.  

The system is designed around storing large amounts of text.  If your source code tree contains a few megabytes of text files the .git file will still be measured in kilobytes. It takes many development-years for source code repositories to hit large sizes.

However, that only holds for text files. When you're storing a few application icons and mouse cursor images the growth remains small because the files are small and rarely changed. If you attempt to store game textures, audio, or compiled object files or executables then growth will be tremendous. 

In one project I was on, the repository was under one megabyte until somebody accidentally submitted their built assets (the obj's, pdb's, dll's, and exe's) for both debug and release builds. Since the automated tools would continue to submit anything already under version control the integrations and branches grew rapidly, the following day the .git file was over one gigabyte. We had to stop all the automation and tell people to stop submitting stuff, then people figured out the right Git commands to cause them to be removed. Then everybody needed to run the series of commands on their own local machines.  It took several days to get sorted out and bring the repository back down to megabyte-scale size.