Git repository with multiple projects that share code

Question

I have some projects that share code.
This is my folder structure:

Workspace
+-- Libs
+-- Project_A
+-- Project_B
+-- Project_C

Project_A, Project_B and Project_C use code from directory Libs. I'm trying to find a way to put them into a repository, here is my options:

1. Put Workspace into one repository.
2. Make one repository for Libs and one for each project.
3. Use git submodules.

There are some issues regarding the first two options.

1. The commit number changes whenever a change is made. For example someone makes a change in directory Project_A and pushes the changes. A new commit number is created in the repo. And it appears that the other projects have a new version too. I could use branches but I'm not sure how easy it would be to update the changes every time for each branch.
2. It's kind of the same issue. Someone makes a change in the directory Libs, then my projects stay with the same commit. They don't appear as new versions. But the executable has changed due to the change of the Libs.

I have no opinion regarding git submodules. I never used it. But I'd give it a try if they are useful in my situation.

Can I use submodules and keep the structure of my project as it pictured above?

Is there any other way I can do what I want?

Answer 1

Most of your concerns seem to relate back to this:

A new commit number is created in the repo. And it appears that the other projects have a new version too.

This is not how version control works, and certainly not how git works.

Firstly, a commit is the state of your source code at some particular moment. It is distinct from a build, which is that source code compiled with particular configuration, external dependencies, and so on.

If you have a version control system that gives each state a unique, incrementing number and you always build with precisely standardised options and dependencies, then you could use that commit number as a "build number".

However, git is not such a version control system: git does not have "commit numbers". A commit is uniquely identified by its hash, which is not an incremental number, but a digest of everything in that commit - the state of all the files, the commit message, author and date, and the hashes of zero or more (but mostly 1 or 2) "parent" commits. For most day-to-day purposes, you can treat commit hashes as random strings; they don't have any meaning related to "versions" of your software.

The other sentence I'd like to comment on is this:

I could use branches but I'm not sure how easy it would be to update the changes every time for each branch.

General wisdom is that with git, branches are cheap. Most workflows using git will have you creating and merging multiple branches every day. I'm not really sure how they relate to your question, though, so I won't confuse things by speculating.

To answer the actual question, all of your options are perfectly fine, and which one you use comes down to a bit of judgement and a fair amount of opinion:

1. You are right that in one big repository, changes to any file will create a new commit of the whole repository; but if you run git log Project_A, you'll get a list of just those which made changes to that directory. You might decide that having cross-project commits is a good thing: you can make a breaking change to "Libs" and fix the Project code in the same commit. Or, you might decide that the projects have different release cadences, and giving each its own repo makes it easier to have appropriate branches and tags.
2. Whether versioning Libs separately makes sense depends partly on your language and build system. You might decide that every change to a library is immediately released as a new tag, named according to Semantic Versioning, and the projects always depend on a tagged version. Or you might decide that it can't be tested on its own, so having the library and the projects always checked out together makes testing easier.
3. I'll be honest I don't know much about submodules. They will have their own compromises, which you should read up on, and decide if they're appropriate to you. There's not going to be an easy yes or no from the level of detail you've given.