Multiple Git repos practices for distributed environment

Question

In a nutshell what I need is a simple good practice for multiple (loosely coupled or tightly coupled), git repositories I would love to hear there is a good framework for that, but I have read a dozen other s.exchanges threads and most simply give a compromise solution, and only one suggested "have a good practice" ... just as an idea

A longer explanation would be :

We deliver distributed environments, i.e- many on-premises integrated SW solutions.

Let's assume these are my "code parts" :

Services :
Service A
Service B
Service c

Shared libs:
db-lib
logger-lib
communication-lib

FrontEnd:
FrontEnd A
FrontEnd B
Android
ios

On an SVN monolith repo it would probably look like this:

--libs
--db
    --logger
    --com
--service A
    --assets
    --tests
    --
--service B
    --assets
    --tests
    --
--service C
    --assets
    --tests
    --
--FrontEnd A - html
    --assets
--FrontEnd B - android app
    --assets
--FrontEnd C - iphone app
    --assets
--FrontEnd D - also html
    --assets

the connection between services can be from interactive μServices, to a solution suite (such an internal organization portal, CMS , and 3rd party API)

Now, lets assume that I have just ran complete set of tests and integrated this environment into a client A on-premises site (his internal business portal).

after a success with this client we want to integrate client B . This client have some requests and we are now developing a new version, testing and pushing to site B. The fixes and features are in many of the above components inc. libs

Now client A has a bug and a minor request for change. And we need a complete set of the above code with the exact versions OR Push him to latest version (not always possible and/or cost effective)

After readings many threads on the s.exchange - dep management such as Git submodule , git subtree , subrepo are not intuitive, not easily configured and does not automatically change, and thus creates extra overhead and are error-prone .

Dep build/dependency tools are usually per-coding language and a mixed solution as the above will not use one solution to rule them all ,

I know there are external tools, and also researched some suggested hacks, most of those "admit" to be a partial solution for a deep challange.

So, regardless of the "tool" (or no tool),
What I would really love to learn is of a good and simple dependency management experience that will allow the developers to easily go back to "a point in time" , pull the right version of the code from each of the repos to a specific hotfix / feature branch(s) fix some code (2 lines of db lib, 3 lines of service B) , push the code , build, test and deploy, and easily repeat this cycle with little pain as possible.

e.g., something like this:
http://nvie.com/posts/a-successful-git-branching-model/
but for dependent multiples repo flow.

Answer 1

May I suggest the Forking Workflow for Git that is used by open source projects?

You may already be familiar with the Gitflow Workflow, wherein master contains the gold standard of the code, and branches are created for each release, each feature, each hotfix and merged accordingly.

The Forking Workflow expands this to multiple repositories. There is an "official" repository that contains the gold copy of the code, and perhaps a branch for each release. Whenever a person wants to work on the code, they fork the official repository to their own repository and apply the Gitflow workfow within their repository. When they have code that is ready to be added to a release, they can merge their feature branch into their release branch then create a pull request to pull their release branch changes into the official release branch. Alternatively, they can create a pull request to pull their release branch to the official repository, which can then be merged to the appropriate release and eventually the master branch.