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.