How to handle shared code with git in this script?

Question

I'm currently trying to switch our version control to Git (from CVSNT). Surprisingly, I had problems with the distribution or concept of an intermediate area. But I have quite a few problems wrapping up the idea that AFAICT operations, such as branching, merging, and tagging, are always applied at the repository level, and not at the file or directory level ...

We reuse our code for different projects. Currently, my workspace is as follows:

/Dev /Libs /LibA /LibB /LibC /Project1 /Project2 /Project3 /WebDev 

Now, let's say Project1 depends on LibA and LibB, Project2 depends on LibB and LibC, and Project3 has no dependencies on lib. Some of these libraries were later compiled into DLLs (or BPL - our main development environment - Delphi), others are just collections of reusable code that are included in the file by file in the main projects.

WebDev contains code for our (mostly static) company website, which also contains information about Project1,2,3 and therefore can be associated with them together.

Since I switch between projects quite often, I usually check all this at the same time, updating the lib directories on the fly to the appropriate project branches, where necessary.

How would I simulate this in Git and would it even make sense to stick with this way of working? I read about Git submodules, but I don’t see how I will apply this for several reasons:

• As I understand it, submodules will always be checked inside their respective “superproject”. However, we found that managing multiple designtimes of library code with Delphi is the royal PITA, which is one of the reasons we keep all libraries under a common directory outside of individual project trees. Additional copies are checked only by building automation, never to do any real work.

• I do not want libs to be "project independent": if I tag or share one of the projects, I always want to tag or branch corresponding libraries. When I want to return to a specific tagged revision of the main project, I want the libs to also return to this state. If possible, tagging / forking / checking should always be done in one step for the project and its dependencies.

I already made one attempt to put everything in one Git repository with library code, which is mainly managed on the main branch, and "projects" each on its own branch, but whenever I try to merge the lib changes between master and the project branches, it pulls to all files from unrelated libraries, and this is not at all what I want ...

Do you have any idea how best to solve this? I am open to almost all offers, including a new layout for my work tree.

If someone could point me to a real practical tutorial on submodules (or any other method that I need for this), that would be great too.

Answer 1

• First: one Git repo per component (Lib component or project, see Git Constraints )
• Second: one parent project (Dev), under which you declare all your submodules.

This way you can quickly check dev and then initialize / update only the submodules you want to work on (including everything if necessary).
When tagged, the tag applied to the parent Dev repo will refer to the exact commits of all submodules, which means: if you revert to an older version, you will return the exact submodules, as in the previous state.

This organization will be a “systems approach” where you can upgrade any part of your components.