Single or Multiple Git repositories for libraries shared between teams
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.
- Date modified in file system does not change when switching branches in Git repo
- RStudio version control timestamps incorrect by 4 hours
- After git merge, This branch is 1 commit behind
- How to use a subversion repository as a template for new projects?
- Completely remove every trace of git commit
- Should I use a software hosting solution for my personal projects?
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:
- 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)
- Easy for others to integrate/reuse the common libraries A-D
- 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).
- 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.
One Solution collect form web for “Single or Multiple Git repositories for libraries shared between teams”
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
It’s possible that my suggestion is slightly complex to implement.