1

I'm an old SVN-hand (and before that CVS-hand) trying to understand Git. I'm trying to put some code under source control using Git, and I'm having difficulty deciding how to organize things. Please indulge me by answering the following question:

In SVN, a repository typically contains multiple projects. In the SVN manual, it says

So we first recommend that each project have a recognizable project root in the repository, a directory under which all of the versioned information for that project—and only that project—lives. (emphasis mine).

A repository is thus conceived as a place where multiple projects live. Although the possibility is mentioned that a repository might contain only a single project:

Of course, if a repository houses only a single project, the root of the repository can serve as the project root, too.

But this is not the main use case and I've never done it that way in my experience.

Repository creation is HARD, and is usually tied to a specific piece of hardware, i.e. a server.

In git, though, the "project" concept is not mentioned, and by "repository" Git intends something more like what I think of as a project. There are repositories all over the place, and one might be central, but the typical documentation seems to imagine that the average user will have multiple repositories all over his machine and these might be tied to multiple repositories on one or more servers. For example, the command "git init" converts a directory into a repository! Nothing could be easier - or more confusing!

I've been banging my head on this question all day, but I really would like to understand the philosophy here. I know this is not the kind of question Stack Overflow likes these days, but I'm not sure where else to take it.

What I'm looking for is a document that addresses this issue dispassionately.

Steve Cohen
  • 4,679
  • 9
  • 51
  • 89
  • Have you seen http://stackoverflow.com/questions/25748978/personal-vs-central-repositories? – jub0bs Mar 24 '15 at 21:55
  • Thanks, I'll give that, and the documents referred to therein a read, but a cursory glance doesn't show me anything about the project concept that's confusing me at the moment. – Steve Cohen Mar 24 '15 at 22:03

3 Answers3

1

In distributed version control systems the repository is a unit of commits and unit of branching. So it contains the thing that is branched together, which corresponds to "project" in Subversion.

Subversion allows branching at any subdirectory level, but that adds a lot of complexity. Distributed systems instead use a non-linear history of the whole repository for branching, but that means branching is only possible at the repository level. It follows that in one repository you place one project.

Distributed system is also distributed. It's “repository” means any place that stores copy of the project history, including each working directory.

That does not mean you are not going to have one central repository. You almost certainly will. But because there is nothing special on it from the point of view of Git, it does not have any special name for it.

It also does not have any special name for place that holds multiple such central repositories, because it does not care whether it is one place. Usually it is simply called a “(central) server”.

Jan Hudec
  • 73,652
  • 13
  • 125
  • 172
  • 1
    I like this answer and thank you for confirming that in git there is a one-to-one between a repository and a "project". But let's take it one step further: Assume we have a group of developers collectively responsible for many projects (project = a separately deployable unit of code). With the name "repository" being given over to the project concept, what do we call the central location where all these projects live? – Steve Cohen Mar 24 '15 at 22:40
  • @SteveCohen: Added to the answer. Git does not have a name for that, because it does not care whether they live in one place. They are separate. I would simply call it a server. – Jan Hudec Mar 25 '15 at 06:02
  • If you have a central server which runs a Github clone (Stash, gitorious, what have you) then that quite naturally becomes the central store. – tripleee Mar 25 '15 at 06:13
  • @tripleee: Yes. But git itself does not care how you organize the central store for your project. – Jan Hudec Mar 25 '15 at 06:27
  • Well and good. I suppose it would have been better if the Git people had come up with a different name than "repository" for this single-project unit, or at least commented on the difference. It is confusing to users of older systems, and the most typical advice given to such folks is to "forget everything you know and just learn to love git." That probably gets peoples' backs up needlessly. It got mine up, I know that. Now that I understand the difference, though, I think I can learn to appreciated the value of git. – Steve Cohen Mar 25 '15 at 13:14
1

Github's article on the subject seems like it would be a good place to start and git-scm.com's documentation would be a good next stop.

Really though, there is not going to be any substitute for diving in, trying things out and reading the built in docs (which are much better than they used to be). I would recommend starting with git help config and see where that takes you.

dak180
  • 71
  • 1
  • 5
0

I just add one more piece of information beyond what has already been said. To gather a set of project together you could use the concept of submodule which is used to hold a reference (location+revision) on another repository within a repository. For example, assuming you have existing project1 and project2 git repository, you could do something like:

$ mkdir metaproject
$ cd metaproject; git init
$ mkdir project1 project2
$ git submodule add <path to project1> project1
$ git submodule add <path to project2> project2

You can then aggregate different revision of different project to something coherent.

davidriod
  • 937
  • 5
  • 14