Git has a helpful ability to ignore certain files. When working on .net projects, you normally want to ignore your .suo file, bin and obj folders etc.
If you’re using the excellent GitExtensions it will even provide a default, reasonable .gitignore file for you.
Problem is, that while you want to ignore certain patterns in most of your project, generally you want none of those rules to apply to your nuget packages.
Everything in packages folder should be committed. Always. No exceptions.
To do that, you need to leverage a child .gitignore file.
Create a .gitignore file inside your packages folder and add the following line to it:
!*
This tells Git to disregard any ignore rules of the parent file. Now all your packages will be committed completely, without missing any of their functionality.
Comments
“Everything in packages folder should be committed. Always. No exceptions.”
Nope. Wrong. Sorry.
Care to elaborate?
They blow out the size of the repo. When you live in places with high bandwidth at low prices (the US) that’s fine. When you live in Australia large git repos are a pain in the arse.
If you care about making sure you’re not dependent on NuGet.org for your libraries you can always set up your own local NuGet repository. This also allows you to do point in time builds.
I’m just sick of pulling 1Gb+ repos that should be <100Mb.
Without committing them, your ability to pull a point in time build is lost.
With committing them, you have a huge repo size and fetches, pushes, and checkouts can take a long time, ruining some of quick efficiencies of git.
The risk outweighs the benefits, imho, but I am getting awfully tired of my long fetches
Very handy tip regarding ignore file but would probably agree with others, checking in packages folder is unnecessary. But that’s just my opinion!
With NuGet package restore, there seems little need to commit package binaries to Git.
Wait what? If your reason is that you lose the possibiltiy to go back in time, you’re wrong. Why? Because your packages.config contain the correct version number that was used in that particular commit. So that’s a no-issue.
Second of all, the size, you know how big your repo becomes when you update your packages? Remember, every time you do a pull EVERYTHING is copied to your local machine.
The ONLY thing from the packages folder that should be committed is the repositories.config, as some tools use that to scan for packages.config and install the correct versions.
+1
“every time you do a pull EVERYTHING is copied to your local machine”
Kristof, Git pull imports and merges commits from a remote repository into your local repo.
How did you figured out that it copies everything, everytime?
Well no, ofcourse not.
Most of the comments here arguing for never committing packages are making the assumption that package restore works for all packages. Unfortunately that is a false assumption. For example, packages which import targets into .csproj files are not restored before the first build takes place and are therefore missing at the moment a project loads which results in incomplete or failed builds. Other solution level packages such as test runners and other build tools suffer from the same problem. At the moment there is no way round these problems which will take care of both the build script and Visual Studio build scenarios, but the core nuget team are working on solution level restoration which should take care of these problems. So whilst it’s probably true that the vast majority of packages don’t need to be committed, for some packages it’s the easiest way to avoid friction until these problems with package restore are resolved.