> However, acting on your advice (which I think is excellent in this case),
> I'll go back to basics and forget about the sharing issue for now.
> From my ongoing reading, I *think* the way Git intends to work is that each
> project is a separate "repository"; am I seeing this right??  Given my
> experience with CVS and Svn, I view the "repository" as the container that
> contains the entire history of all projects that I have ever worked on.  I
> am suspecting that this world-view will not work with Git...

Yup, you're on the right track there.

> But if this Git world-view is correct, where do I keep a central collection
> of all of my projects (what I call "the repository"), so I can (for example)
> back it up and have everything secured somewhere???  It seems like Git wants
> to make all of my projects completely unrelated to each other - but they're
> not!!  They are all projects that I'm responsible for, and need to be able
> to collect and control in various ways...

You should use a Git repository manager, like GitBlit, GitLab or
GitHub (there's myriad of different ones, but I won't get into how to
pick the right one here). Many of these offer to organize repositories
into some sort of group, which can help you or your team keep track.

Then when it comes down to efficiently dealing with multiple
repositories, here are some ideas:

* Group repositories locally by bundling them in normal directories
* Use gitslave, or myrepos to check out many adjacent repositories in
one command
* Consider git submodules if you want to add the sources from one repo
into another (library code that does not change often). If submodules
don't work for you, try subtree.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to