Source: own resources, Authors: Agnieszka and Michał Komorowscy
Some time ago I decided to publish my projects on GitHub. This decision had very positive repercussion because it mobilized me to do more refactoring and to clean my solutions. Additionally, I switched totally to management of external references via NuGet. Earlier, I had some binaries in a dedicated directory on my computer. It took me some time but it was worth doing it.
I also had to solve the following problem. I have a solution called 
Common. It is a collection of libraries, utilities, algorithms, helpers etc. that are used in my other projects. Before migration to GitHub, after a build, all 
Common binaries were copied to the well known location i.e. 
N:\bin Thanks to that all other projects could reference them from this location. It works. However, if someone wants to download my projects from GitHub, he or she will need to create a mapped drive 
N manually. I din't like it.
The next step was to switch from absolute references to binaries to relative references to projects. For example let's consider a library 
MK.Utilities and a project 
LanguageTrainer that uses it. Initially 
LanguageTrainer was referencing:
N:\bin\MK.Utilities.dll
After migration this reference was changed to:
..\..\Common\MK.Utilities\MK.Utilities.csproj
Much more better, isn't it? Still, it is not perfect. This relative path will work only if the folder with 
Common and 
LanguageTrainer solutions will be in the same place on the disk. Besides, in order to compile 
LanguageTrainer solution 
Common solution must be built first. What's more 
Common and 
LanguageTrainer are two separate repositories which have to be downloaded individually. My goal was to be able to download any repository/solution and then be able to compile it without any further steps.
I started reading about possible solutions and I found information about 
git submodules and g
it subtrees. There is so much about them in Internet so I will not repeat others. For example see this 
post. At the end I decided to use 
subtrees. Simplifying a subtree is a copy of some repository in the another one. Returning to my earlier example, by using subtrees I got a copy of 
Common repository/solution in 
LanguageTrainer repository/solution. Then I could change the reference to 
MK.Utilities as follows:
..\Common\MK.Utilities\MK.Utilities.csproj
Besides, I needed to add 
MK.Utilities project to 
LanguageTrainer.sln solution so that all projects could be build at the same time. Finally, my 
LanguageTrainer repository/solution looks in the following way. On left side you can see GitHub and on the right side Visual Studio:
If needed I can refresh a copy of 
Common repository/solution inside 
LanguageTrainer at any time. Why I used subtrees? Well, they work for me and are 
extreamly easy to create via 
Source Tree ;) By the way, I like 
 git but I hate all this complex commands. Source Tree solves this problem and allows me to use 
git via friendly GUI. I strongly recommend it.
At the end I had to solve one more problem with Nuget. Let's return again to my example and let's assume that 
LanguageTrainer solution is located here:
C:\LanguageTrainer
In that case, by default, Nuget packages will be located here:
C:\LanguageTrainer\packages
However, we also have a subtree:
C:\LanguageTrainer\Common
And projects from a subtree expects that their packages will be here:
C:\LanguageTrainer\Common\packages
Of course they won't be there so 
Common projects will not compile. To overcome this problem I had to manually update 
csproj files and replace 
..\packages with 
$(Solutiondir)packages. For example:
..\packages\structuremap.3.1.6.186\lib\net40\StructureMap.dll
Was changed as follows:
$(SolutionDir)packages\structuremap.3.1.6.186\lib\net40\StructureMap.dll
I hope that this post will help you in your struggles with GitHub, Subtrees and Nuget.