Managing Internal Shared Libraries with Git and Nuget

Question

I have just started splitting up our Git repository that houses all of our product code, which includes shared libraries, server, client, and tooling code.

As a part of removing some of the tech-debt we have with our DCVS, we are proposing moving our shared client, and server libraries to a Nuget archive that will have tightly controlled push permissions on the development and release branches to force facilitation of pull requests that we have been slack with. The splitting part is no big deal; I have tailored git filter-branch to my liking with respect to history retainment, and am now looking at how to stitch repositories back together.

At the moment, the libraries are not entirely clear-cut and need some heavy refactoring before I am ready to package them up (as well as proper unit testing, and the like) and would like to be able to make changes to both repositories, with an emphasis on code review, as a short to medium term solution.

I have read enough about both git subtree and git submodule to understand their relative strengths and weaknesses, but am still conflicted about what to do. While an overwhelming number of resources protest against using git submodule due to its fragility to those unknowing of how to use it (guilty!), it's alternative git subtree seems to lack that explicit referencing features I am looking for.

If anyone has a similar setup to what I am looking for, or has a similar workflow done differently, could you comment on it? I am going to go away and test the two strategies while I "wait for a bite", and will hopefully have a more elevated assessment.

both could help (subtree and submodule): see http://stackoverflow.com/a/1307969/6309 — VonC, Aug 02 '14 at 03:57
What do you mean by explicit references? I was guessing you're talking about referencing specific revisions of the child repository, but that's a workflow specific to submodules you wouldn't need for subtrees; it's more automatic in that the parent repo would just be checked in with the child repo in the correct state. — johnb003, Aug 05 '14 at 18:01
I would recommend gerrit repo: http://stackoverflow.com/questions/24433332/submodules-subtrees-or-something-else-for-dependencies-in-git/24847587#24847587 — onionjake, Aug 19 '14 at 02:26
Just want to give an update on the situation. For the moment, all the projects are currently being distributed via submodules. It has been a bit of a steep learning curve for the team, but once we move some things over to Atlassian Stash, there can be some more strict policing in the form of pre-receive hooks. Ideally, everything will be an independent Nuget package with unit tests, but at the moment, our code is too intertwined. If anyone is curious as to how the splits were done, I wrote a quick [blog article](http://blog.danubers.com/?p=18) outlining the process I undertook. — Daniel Park, Sep 20 '14 at 07:32
Just as an update, I have long since diverged from this pattern. Instead, the build process now has steps to package NuGet packages with sources, and publish as a part of an automated build step. So far, this has worked well, but only with heavily decoupled code. It has been a bit of an effort, but now it is paying off nicely. — Daniel Park, Oct 27 '15 at 22:34

score 2 · Answer 1 · answered Sep 02 '15 at 16:24

We recently moved to Git from a more traditional version control system. Long before I started we had adopted the habit of checking libraries into the version control. Obviously this does not work well in Git, nor was it a good idea in the other VC. So we ran into a similar set of choices to yours. After reviewing subtrees and submodules we have decided to use neither. We have multiple repositories that are cloned as peers:

  <some folder>
             |
             + <repo1>
             |
             + <repo2>
             |
             + <repo3>
             |
             + <packages>

We also use Nuget to handle our libs (note we are developing in C and C++ not .Net). Nuget works well enough for native libraries and we have not found an alternative. The process is much more manual than I would like, but it does avoid a whole set of "interesting" issues that seem to plague both submodule and subtree.

Hope that helps.

Managing Internal Shared Libraries with Git and Nuget

1 Answers1