Git – How to Share Code Across Multiple Web Projects Using Git

dependency-managementgit

I work in a small team that creates and maintains quite a lot (> 100) of ASP.NET website projects. Our current workflow is that our projects are all located on a network drive, which everyone works from directly. We have a couple of shared code libraries, which contain both binaries and css, js and xsl files. With each addition to this shared code, the files are distributed by copying them to all projects on the network drive using a script.

Our current project "layout" looks something like this:

Shared code project
   |- Deployment (compiled binaries)
   |- Library (C# source code)
   |- Web (a website project that contains the default css, js, etc)
       |- css
           |- default (shared css code)
       |- js
           |- default (shared js code)
       |- xsl ... etcetera

Website project
   |- Bin (shared code binaries)
   |- css
       |- default (shared css code)
       |- specific (project specific css)
   |- js
       |- default (shared js code)
       |- specific (project specific js)
   |- xsl ... etcetera.

I'm currently in the process of trying to get us to switch to using git and working locally on our own machines. I've got most potential issues covered, except for how to deal with the shared code. Obviously we can no longer use the copy & replace script if we're all working locally. So something a bit more sophisticated will have to be put in its place.

If I was using SVN I might use svn externals to reference certain files in the shared code repositories. The nice thing with that is that I can pick just those files I need (no C# source code), and put it exactly where I need it to be. But with git that doesn't really seem to be an option. I've been reading a lot about git submodules and subtrees, but neither seem to be the ideal candidate.

I have also considered using a package manager like NuGet or Bower, but is this really a good idea for first-party dependencies? For one, it would mean that everyone who would want to git clone a website project would have to have the package manager installed.

What would a typical git setup for a website project with "first party" dependencies be?

A few details that I think are relevant to the choice:

  • I only need one-way synchronizing. Changes to shared code are made in the shared code libraries. I don't need to be able to push to shared code libraries from a project library.
  • The shared code libraries are updated and distributed relatively frequently; a few times per week at least.
  • Both shared code libraries and website projects will be git repositories.
  • I don't want to pull in the C# source code for the shared binaries.

Best Answer

You could stand up your own, private NuGet package feed on an internal server in your company. Publish each dependency to your NuGet site as a separate package and use NuGet to manage those dependencies. Furthermore, if you need to make code changes to a package you can create a local package feed so you can change code, compile and update. When you are ready to share with coworkers, tag and push in Git, then publish to your company feed.

Hosting Your Own NuGet Feeds (NuGet Docs)

The nice thing about this approach is you get backwards compatibility with your packages. You can make API breaking changes without requiring other projects to be on the same release cycle as yours. As an added bonus project structures probably wouldn't be affected if you change source control systems.

Related Topic