Question

This surely has to be a duplicate since its a common scenario, if so pls direct me to a good link.

I have common project (class library) that will be used across many solutions, say, a common solution which I will call dll shared between solutions A and B. So this is how the directory structure right now is:

Solution Common (dll)
      - Project Common

Solution A
      - Project A1

      - Project A2

      - Project Common #only referenced, so logical presence, not in real

Solution B
      - Project B1

      - Project B2

      - Project Common #only referenced, so logical presence, not in real

Now what I need is

  1. a git repository in dll so that I can commit the changes i make to dll files.

  2. a git repository in A so that I can commit the changes i make to files of A as well as dll files. (Since in visual studio I have both projects under one solution, editing them both is easy but I should be able to commit them both together). Also it would be welcome if I could pull any specific commits of dll that was made from dll repository, but its not absolutely necessary.

  3. Same as above for B.

Basically I need 3 repositories so that I can individually commit in 3 different solution folders but I also need the ability for dll repository to be shared between A and B from which I can commit and pull etc.

My questions are:

  1. Is it possible?

  2. If so how would I structure my repositories?

  3. How will I commit/pull dll and A together?

One solution that is already coming to me is to have one giant repository for all the 3 solutions outside its scope but that seems so inelegant as I have other solution folders too along with A and B.

Was it helpful?

Solution

I confirm this is what git submodules (mentioned by madhead) are for, but you need to realize that a submodule is first a fixed reference to another repo.
You can make modifications directly in a submodule, but you need to:

  • commit in that submodule, and pushing to its upstream repo
  • cd back to the parent repo
  • commit in that parent repo (recording the new reference for the submodule) and pushing to the parent upstream repo

(See more in the "true nature of submodules)

This is well suited for a component-based approach, where each module can evolve independently, and specific revisions of said modules are combined in order to form a complete program.
(your "giant repo" would be a system-based approach, where all modules are writable, and in their latest revision)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top