Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Single or Multiple Git repositories for libraries shared between teams

I am looking at how/if I should make the switch from svn to git.

I currently have a multi-layered set of projects in svn which are layered such that D uses C which uses B which uses A. Actual deployed projects like X,Y,Z use any of the common libraries A-D. The aim is for future projects and other teams to share the base libraries (A-D) and to enable better branching control.

In svn if we wish to allow other teams to use library C without getting involved with X,Y,Z then it is simple, they just check out the C bit of the svn tree, if that leads to them wanting to patch B, then ditto. They never touch X,Y,Z even if they are in the same actual repo. It is not so obvious what happens with git.

If I wish to set something up using git, how would you suggest I set it up and what are the upsides/downsides with your suggested setup.

Features I am looking for are:

  1. Simple tagging (if possible) so can tag the state of the whole codebase easily (simple with a common svn root or a single git repo)
  2. Easy for others to integrate/reuse the common libraries A-D
  3. Simple for them to give us back suggested fixes/patches which we can choose to take or ignore (one of the main things I want from git).
  4. Teams to have effectively private ownership features available for shared libraries (so they can tag them and fix them for themselves on their own timelines)

Git seems to offer what I want, I am just not sure how to deal with the single vs multiple repos problem.

like image 881
DaveC Avatar asked Feb 28 '10 17:02

DaveC


People also ask

Should I have multiple Git repositories?

With Git, using multiple repositories is the only way to work efficiently. This enables each team to work independently, and do their work faster. You can also make sure that developers only have access to the repositories they need access to (thus making Git more secure.)

When should I use multiple repositories?

Having multiple repositories makes it easy to give access to subsets of repositories on a “need to code” basis. I set up Continuous Deployment for my projects. It's much easier to let each repository have it's own process for being deployed.

How many Git repos should I have?

keep the methodology as it currently is, with one repo per solution.

Can there be multiple repositories for each project?

It is a combination of two Git tools that you can use to manage multiple repositories within one project. The two tools are HelixTeamHub and Helix4Git Do. Here, HelixTeamHub lets you work with multiple repositories, whereas the developers can use Helix4Git to contribute to the sub-projects or repositories.


1 Answers

If I wish to set something up using git, how would you suggest I set it up [...]

Just go with multiple git repositories (they are quite cheap and they are akin to many small boats instead of a Titanic--in other words, I find that they are flexible and I love flexibility).

Now and then I assist with a project that is structured like so

foo/server
foo/client
foo/docs
foo/tools/

The 'server', 'client', 'docs' and every folder in 'tools' are separate git repositories. This allows specialized team members to clone and work on exactly what they wish to work on.

Not to mention, if we just want to pull in everything, we can clone foo (which pulls in the rest as sub-modules).

It's awesome that git allows you to do this so why not take advantage of it?

[...] and what are the upsides/downsides with your suggested setup.

It's possible that my suggestion is slightly complex to implement.

like image 194
Fake Code Monkey Rashid Avatar answered Oct 19 '22 19:10

Fake Code Monkey Rashid