At my work we have multiple products.. productA, productB, ... these products reference multiple components. componentA, componentB.. there are also shared components sharedA, sharedB... etc.. which are either shared by multiple components, multiple products or by a product and a component.
We are currently moving all these things to separate Git repositories however, we have a hard time find a way to set up repositories in such a way that everything stays manageable.
We have two problems that make setting up repositories hard.
There are a lot of hard dependencies. When I want to work on ProductA I need to have the source code for ProductA, componentA, componentB, and sharedComponentC on my computer, since I might be changing code in all of them. For ProductB I need componentA, sharedComponentC and... this makes it hard to choose what to store in what repository.
Say componentA is an interface library, this interface library is used by ProductA and ProductB. For ProductA it needs to work normally but in ProductB it needs to show an extra button. We have a lot of these very small differences in components should we make a branch per product and sometimes integrate the branches to make sure they have the same new features? Maybe develop on a 'general' branch and push changes to each 'small difference' branch? Is it bad to have a lot of active branches in a project?
Are there any rules of thumb that help to decide how to split software over multiple repositories? What are good ways to work on software that is in multiple repositories, or tooling that helps in this regard? What is proper repository set-up for components with a lot of small differences? In the end these are all the same question. What is a good repository strategy for multiple interconnected components with small differences?
Some more information that might help. We develop solely on Windows, 99% of the code we write is C#, the other 1% is C++/CLI. All our developers have access to Visual Studio 2013 Pro. We are willing to buy software to help us with this problem but we are a small company so we do not have infinite budget :).
Of course a part of the problems we are having are due to (bad) design decisions in the past. (No design decision can completely safeguard against the future development of your software/company ;) ) We are working on changing that. But for the time being we would like to decide on a modern repository strategy that makes things a bit more manageable.