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. 
Repository strategy for multiple interconnected components with small differences
c#;version control;git;svn;repository
With git you can use git submodule.ProductA can have specific commit_ids (which can be a branch) of some submodules (for example ComponentA, ComponentB, SharedComponentC).To add a component to ProductA, from the ProductA directory on your development machine do:C:\projects\ProductA.git\> git submodule add --branch master --name ComponentA http://reposerver.ourcompany.com/ComponentA components/ComponentAC:\projects\ProductA.git\> git submodule add --branch master --name ComponentB http://reposerver.ourcompany.com/ComponentB components/ComponentBC:\projects\ProductA.git\> git submodule add --branch ProjectA --name sharedComponentC http://reposerver.ourcompany.com/ComponentC components/sharedComponentCOther developers can use:C:\projects\ProductA.git\> git submodule initC:\projects\ProductA.git\> git submodule updateto receive the correct versions of the submodules in their working directory.When you make some changes to a submodule, you commit the changes of the submodule and you commit the new version of the submodule in the project, i.e.:C:\projects\ProductA.git\components\sharedComponentC\> git add ...C:\projects\ProductA.git\components\sharedComponentC\> git commitC:\projects\ProductA.git\components\sharedComponentC\> cd ..\..C:\projects\ProductA.git\> git add components/sharedComponentC:\projects\ProductA.git\> git commitRemarksI used command-line syntax to explain how to use git; you are free to use any graphical tool or visual studio plugin that you like.I checked the syntax and parameters under Linux and translated the examples to Windows command prompt, so there might some mistakes (e.g. slashes instead of dashes); refer to the git reference manual for the exact syntax.The project directory (C:\projects\ProductA.git), branch name (ComponentA), repository location (http://reposerver.ourcompany.com/ComponentA), and submodule directory (components/ComponentA) can vary independently.