Structuring related components in git

My team is considering a move from about 2 dozen s开发者_运维问答ubversion 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):

• can you make evolution on php or java module without having to make any modifications to other modules (like the obj c ones)?
• can you isolate in a branch some evolutions/fixes which are only made for one of those modules and not the others?
• can you reuse a specific version of one of those modules in several projects?

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.

---

You have at least two options:

• Submodules
• Subtree Merging

If your projects are mostly private, I'd recommend you sticking to the former. Read docs, it is all easy.

---

I don't know much about Git workflows but I do know you have at least three choices:

1. To each project its own repo, probably the safest option. Tags and good testing tools are your friends.
2. Separate branches per project group and to each project its own branch. Be sure to back everything up before doing this. See Scott Chacon's video on empty branches. I have not done this before but Github's gh-pages branches are a live example.
3. Submodules. Each project gets its own git repo, inside a git repo themselves. Probably the best idea around.