Using Git in a Company?

At my workplace we have one large Subversion repository which holds about 100 projects. Some projects use each other through svn:externals. Usually all people have read+write access to everything, but sometimes external people and interns have only restricted read/write access to some custom folders so they don't get our crown jewels.

How would you structure this in git? Each Project its own repository? how can you reuse code? Can you somehow implement access rights?

From stackoverflow

• Structure: Yes, 1 project per repository. Git is designed for it to work this way and it does it quite nicely.

  Reusing Code: Use git submodules (very similar to svn:externals, only better)

  Access rights: Yes, access control is often built around ssh and public keys. If you want to host it yourself, try gitosis, but I actually highly recommend a hosted solution, like GitHub.

  Adam Byrtek : I absolutely wouldn't keep the source code of my company on a hosted application like GitHub.

  Ryan McGeary : Adam, That's a fair opinion, but please give a reason. Is it a lack of trust, need for power, cost, etc? Personally, I have no problem releasing some control (and admittedly taking a very small risk) for convenience and economic sense.

  krosenvold : I think a fair amount of companies would be sceptical of putting their core IP on a remote site.

  Ryan McGeary : Being skeptical is a good thing, but being unable to calculate a risk/reward ratio isn't. The risk/reward ratio is obviously different for each company, so roll your own gitosis setup if you need to.

• I would use a single git repo, if you don't need to restrict read access.

  Structure: filesystem hierarchy

  Reusing code: trough the build system

  Access rights: write access is patch merging. It can be controlled by script or best, by a designed person. If you have like 3 projects, each has a project manager who is responsible for merging code in the main branch. Remember, this is how linux works and git is especially well tailored for that scenario.

  Why use a single repo ?

  The main reason is regarding code divergence. Let's say you have that 3 projects and some shared libraries. Team A needs to adapt libXY's interface and commits the code, with two scenarios:

  1. Submodules: Team B and C will then have to update their submodule and report to Team A if the changes broke their code. They can also update the code themselves, but then Team A might also have some code breakage.

  2. One-big-repo: Team A changes the code until all tests pass. Changes gets merged upstream and everybody is happy.

  Running all tests in scenario one is also possible, but then, it's the same as if you have one repo since you had to checkout all code.

  This is my point of view. Maybe you have some big assets in a repo you don't want everybody to checkout because they take like 2GB. Maybe your code base is so big that the overhea doesn't matter.

  But I believe that unless you are Google, IBM, ... the overhead you'll pay to manage multiple repos will be too big and make you loose time you could have spend on more productive things.

  Cheers, zimbatm