Well, I took a look at this post GIT Version Control setup for multiple projects with shared code, but turns out that I don't really think it answers exactly what I want because that is too complex (i guess) for what I need.
I work in a company and we have over 4 projects. They are versioned currently by SVN in one repository only. We are moving to GIT and I find lots of tecnical answers about GIT or SVN but what I'm looking for is a theoretical answer about general usage of version control.
One of our projects is a plugin that we use as a framework for almost all of the projects. The plugin is something in common among the projects, but it's the only thing in common, because the other projects are absolutelly diferent from each other.
Sometimes I'm working on a project and I have to change something in that plugin that we use as a framework for the others, for example to provide multi-tenant support for the projects and someone else might be at the same time working in another project and changing something in the framework plugin.
The situation that I discribed above is what makes me think that I can't put each project in a different repository since all of them will need the framework plugin. However all the projects are different (totally) and it kind of makes me think that I should host them each one in a diferent repository.
Question is: Should I use one repo for all or one repo for each?
As long as you've already started moving towards Git - don't stop! Git has a concept of submodules which you can find pretty useful in your situation.
Also, IMHO it's not a good idea to have one repo for all the code, as it's a good practice to have one repo per app.
Dependending on the language you use for you projects try to create a "library" from every shared codebase and gain benefits from dependency management available for that stack.