My team is considering a move from about 2 dozen subversion repos into git repos. What we are trying to remedy is that currently, everyone has their own subversion repo for each of their product components. What I’d like to do is try to reduce some sprawl we have and help build a clear path forward.
I’m looking for advice on how to structure the repos. One sticking point is how to group related projects. We have two products. Each product has a set of web services code (php), android client code (java), iphone client code (obj c), ipad code (obj c) and website client code (php + js). Currently each owner has their component in a separate svn repo.
My thought was to try to combine these components together into one repo, but I can’t tell if that is a good practice with git. Does this provide any real benefit over having separate repos? It would seem to foster a better social contract for the quality of what gets checked in because of the common visibility, but are we going to pay for that in other ways?
The criteria for combining different set of files in one “component” (here one Git repo) is their respective development lifecycle (the way they evolve in term of labelling and branching):
If yes, a component-based approach is best (i.e. one git repo per module), as opposed to one repo with everything in it (system approach).
See for instance “Component based web project directory layout with git and symlinks“.
A component represent a “coherent set of files” and is best managed in its own Git repo.