A little background on my question, I am completely new to .NET Framework. I inherited a large project that has many dependencies and the solution is too large to upload onto GitHub. This project currently does not use any version control. My question is what is the best practice for .Net projects regarding version control with projects of this size? Any help or suggestions would be very much appreciated.
I have tried uploading to GitHub and got an error message about file size.
CodePudding user response：
It seems that the problem is the size of a file (files?) in the repo, not the size of the repo. AFAIK Github's hard limit for a single file is 100Mb.
Scan you repo for large files and store them somewhere else.
Ensure that you are not uploading binary output files. Get a .net specific .gitignore file, e.g. https://github.com/github/gitignore/blob/main/community/DotNet/core.gitignore (save it as
.gitignore, not as core.ignore).Make sure you're organisation is OK with uploading the source to github and that the repo is private.
CodePudding user response：
I inherited a large project that has many dependencies and the solution is too large to upload onto GitHub.
In fact, the fact that the project is large is not the problem. I imagine that your project is smaller than a lot of opensource or closed source project successfully managed with git.
Your real problem is, as Git is a DVCS (Distributed Version Control System), where all the contents are fetch during a clone, the repository should be kept not too big.
That's why, with such tools, you should avoid as much as possible storing binaries in the repository.
And here, your problem is that you have at least one (surely, binary) file in the history that is bigger than 100 Mo (which is the limit set by GitHub).
So you have 2 possibilities:
You absolutely need these binaries in the repository. Have a look at the Git-LFS feature that allows use (in very simple terms) to store the binaries in the server next to your repository. Easy to set up but it is a paid GitHub feature. You will have to migrate all the commit history to git-lfs (but from what I understand, you don't really have source history, so it should not be a problem)
You are able to delete the blocking binaries (because not needed), host them somewhere else (if you don't need versioning) or create nuget packages (or similar) and host them in private and/or public feeds so that in the end, your repository will contains only text files (and very small binaries not updated often) so that you are able to push it in GitHub.
PS (reminder): all the binaries that could be retrieves or regenerated one way or another (like build outputs) must be ignored and never committed in a git repository.